Bug in volume adjustment (bad RVA2 tag)

by **Steegy** » Sat Jan 13, 2007 6:05 am

Modified quote: this should start in some 2 weeks (I think it'll be Alpha testing first).

by **Dieter** » Sat Jan 13, 2007 5:54 am

Great!!!

Is there already a timeframe for starting a beta test phase?

by **jiri** » Sat Jan 13, 2007 4:25 am

Yes and Yes.

Jiri

by **Dieter** » Fri Jan 12, 2007 6:26 pm

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)?

by **Peke** » Tue Jan 09, 2007 7:45 pm

"Fresh"

by **mikem8** » Tue Jan 09, 2007 12:40 pm

Cool and the gang.

by **jiri** » Tue Jan 09, 2007 5:51 am

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

by **jiri** » Fri Jan 05, 2007 1:29 pm

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

by **mikem8** » Thu Jan 04, 2007 3:21 pm

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

by **jiri** » Wed Aug 03, 2005 6:32 am

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

by **wricken** » Wed Aug 03, 2005 3:34 am

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?

by **jiri** » Tue Aug 02, 2005 1:29 pm

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

by **wricken** » Tue Aug 02, 2005 9:49 am

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

by **jiri** » Tue Aug 02, 2005 8:46 am

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

by **Guest** » Tue Aug 02, 2005 7:26 am

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?

Bug in volume adjustment (bad RVA2 tag)

Post a reply

Expand view Topic review: Bug in volume adjustment (bad RVA2 tag)

RVA2 gain bytes supposed to be Big Endian.