MediaMonkey forum

Hi,

I found in my mp3 library a lot of files where the RVA2 tag was corrupted. Most of them contained 14 bytes of data, some 9. A working RVA2 tag written by MediaMonkey should contain 8 bytes of data.

Example:

OK:

0: RVA2
4: 1 (bin) 8 0x00 0x00 0x01 0x85 0xF2 0x10 0xFF 0xFF

Bad (one single 0x01, probably that one denoting the master volume, in the beginning):

0: RVA2
4: 1 (bin) 9 0x01 0x00 0x00 0x01 0x85 0xF2 0x10 0xFF 0xFF

Bad (the six bytes describing the master volume duplicated at the beginning):

0: RVA2
4: 1 (bin) 14 0x01 0x85 0xF2 0x10 0xFF 0xFF 0x00 0x00 0x01 0x85 0xF2 0x10 0xFF 0xFF

I corrected all tags using a little program based on id3lib, and now all tags are working again...

Wilfried

I don't know what exactly do the numbers mean, I suppose they are taken from some application. Here's a sample of RVA2 written by MM and I don't see anything wrong about it. Do you?

52 56 41 32 00 00 00 08 40 00 00 00 01 14 F3 10 FF FF

Jiri

The "numbers" you see is the output from a simple id3 parsing utility written by me based on id3lib (www.id3lib.org), the reference for parsing id3v2 tags.

You see the frames and fiields, frames together with their ID (0) and TextID (RVA2), fields together with their ID (4), Type (1 (bin)), Size (8, 9 or 14) and Binary data (0x.. 0x..).

So your 52 56 41 32 00 00 00 08 40 00 00 00 01 14 F3 10 FF FF is something like RVA2 ..., and the user data (the real content of the RVA2 tag) is 00 00 01 14 F3 10 FF FF which is perfectly well.

However, as I mentioned in my post, I found a lot of tags with binary length 9 and 14, which (with length 14) would read in your notation

52 56 41 32 00 00 00 0E 40 00 01 85 F2 10 FF FF 00 00 01 85 F2 10 FF FF

which is bad. Understandable?

The example you sent is indeed wrong, however as I study the tagging code, I don't think MM could have written this. Haven't any other application modified the tags?

Anyway, comparing it all to id3 documentation I noticed another issue: Identification is only a 'text string', i.e. without encoding byte. For that reason there is one 00 byte incorrectly in RVA2 frames written by MM. So the example I send above should correctly look like:

52 56 41 32 00 00 00 07 40 00 00 01 14 F3 10 FF FF

Jiri

Indeed, I always wondered about the two 0x00 bytes at the beginning of the user data of the RVA2 tag.

The ID3 Tag is not modified by another application, only by MM (for sure, because the only app I use is MP3Tag v2.32 and this one DELETES always the RVA2 tag ...)

However, the wrong data always looks the same: Either it is a 0x01 prepended or it is a 0x01 0x.. 0x.. 0x10 0x.. 0x.. prependend, which is exactly a copy of the next 6 bytes, which in fact contain the volume adjustment for the master channel and the peak value.

Looks like the data being pasted at the wrong offset in an existing tag.

Would it help to send you such an MP3 file?

Wilfried

MM uses ID3lib for ID3 tags read/write operations and I just confirmed that the code in MM _always_ writes 7 bytes, where 1 is terminating 0 of Identification string and 6 bytes describe the adjustment (actually, I'm talking about MM 2.5 now, in 2.4 there's accidentally one more 00 byte written. So I really can't imagine how MM could write other lengths of RVA2 frames.

Have you tried to re-analyze the tracks (make sure you allow re-analyzing of already analyzed tracks in Options)? I'd say that RVA2 should be correct then.

Jiri

The problem is that I've corrected the bad tags now using id3lib. I have some tracks with bad tags on my iPod, but I'm pretty sure that if I insert these tracks in my MM library MM will not be able to understand the RVA2 tag and therefore it will not display the volume adjustment and overwrite it if I analyze these tracks.

Wilfried

BTW: Is 7 or 8 the correct length for the user data?

The length of RVA2 frame can be pretty much anything, it depends how many channels and in what precision is written, but in the format MM uses (i.e. master volume, 16 bit precision) 7 is the correct length (will be in MM 2.5).

Jiri

If I'm not mistaken it appears that MediaMonkey is storing the RVA2 volume gain bytes in little endian.

I confirm this by comparing my calculation with that displayed in MM.

The id3 spec says everything is supposed to be in big endian, as does the ReplayGain spec, and madplay (libid3tag) expects it to be in big endian.

I'm having to code a special case for my RVA2 parsing for MediaMonkey. I'm not sure how I can distinguish an MM RVA2 from others other than the fact that MM's the only app I know of writing an RVA2 into a v2.3 tag.

Just curious, why did you choose to write RVA2 into 2.3 tags? Why not just use the TXXX frames? I applaud you for not writing id3v2.4 tags as the implementations of 2.4 appear to be widely incompatible, not to mention no id3lib support for it. But I'd like to suggest that you stick with the id3v2.3 "standard" and just use the custom "TXXX" frames.

Thanks,
Mike

Thanks for the info, you are right, it's really wrong, we somehow missed that need to use big endian on RVA2.

As for usage of RVA2 in ID3v2.3, it seems to be the best option from compatibility point of view to write v2.3 tags, but use some some fields specified only in the newest version, i.e. 2.4.

Now, due to the bug you have discovered it seems that the best approach will be to abandon RVA2 and write RGAD instead. It's probably used more often anyway.

Jiri

So I can just confirm that RVA2 will be no longer saved in MM 3.0 (due to reasons explained above), but it will still be read in order to support data saved by MM 2.5 and older. In addition, RGAD frame and TXXX frames will be saved (and read) so that MM will achieve maximal compatibility with other applications.

Jiri

Cool and the gang.

"Fresh"

jiri wrote:So I can just confirm that RVA2 will be no longer saved in MM 3.0 (due to reasons explained above), but it will still be read in order to support data saved by MM 2.5 and older. In addition, RGAD frame and TXXX frames will be saved (and read) so that MM will achieve maximal compatibility with other applications.

Jiri

Does that mean the MM will be compatible to replay gain values written by foobar2000?

And even more important: Will MM 3.0 support album gain in addition to track gain (the only reason I have to use foobar2000 in addition to MM is that MM does not support album gain)?

Yes and Yes.

Jiri