Volume calculation stored in wrong format [F4038 RC4]

[tobbbie]

Dear MM team,

...I use PocketPlayer from www.conduits.com on my smartphone and have problems there with the calculated volume levels from MM. I submitted several files to them that had MM calculated the volume. Their analysis is attached below. For questions related to that, please get back to them via email (referenced below).

thanks + bye
tobbbie


-------- see blow --------

Thank you for these two addtional tracks.

You will need to submit a bug report to MediaMonkey - their RGAD peak values
are definitely not big-endian floats (which is the standard) but are
little-endian fixed point values. They are writing out little-endian 32-bit
integers to the RGAD frame with a value of 1.0 scaled to 0x800000. For
example, a peak value of 0.198212 is calculated as 0.198212 * 0x800000,
which is 0x195f00, which written to the RGAD tag as 0x00 0x5F 0x19 0x00. The
specification says that these values should be float values, and we have
seen RGAD tags from other applications that adhere to that standard: an
IEEE754 32-bit float value should be written to those bytes in big-endian
order.


Thanks again!


Carrie Hall
Conduits Technologies, Inc.
http://www.conduits.com/




-----Original Message-----
From: tobbbie
Sent: Friday, November 23, 2007 5:52 PM
To: Carrie Hall
Subject: Re: Replay Gain - strange handling of pre-amp + gain

Hi Carrie,

...please find attached two other files. The classical is a new rip of a
collection I bought recently and there is no other filehistory on it except
with MM 3x. For the others I am not sure what version of MM may have written
which tag. I freshly calculated the volume with MM 3.0.0.1105 and it shows
the very same behavior.

bye
tobbbie



----- Original Message -----
From: "Carrie Hall" <carrie@conduits.com>
To: tobbbie
Sent: Friday, November 23, 2007 10:36 PM
Subject: RE: Replay Gain - strange handling of pre-amp + gain


Hi Tobias,

The file you sent contains a peak value that is not correct. You may want to
report it as a bug in their beta version. The file contains an 'RGAD' tag
whose first four bytes should be a big-endian float value of the track's
peak. You can see this later in the tags under a duplicate tag, under "TXXX
replaygain_track_peak" with a value of 0.188782. The RGAD's hex value is
0x02 0x2A 0x18 0x00. Converted to float (in either big or little endian), it
comes out to an extremely small floating point value (2.21e-39 and 1.24e-37,
respectively). You can see this in our Media Properties screen, as the peak
is rounded down to zero. Having this value incorrect will mess up any
calculations if "Clipping prevention" is enabled. The other parts of the
RGAD tag seem to be valid and parsed correctly, the track has a gain of 9.4
dB and an album gain of 1.35 dB.

We then installed the 3.0.0.1105 version of MediaMonkey and analyzed the
track separately. It wrote out an RGAD value of 0x00 0x2A 0x18 0x00. Even
then, that doesn't specify a valid floating point number. The correct value
it should be writing is roughly 0x3E 0x41 0x50 0x12, which is 0.188782 in
big endian float.

We will add TXXX parsing to Pocket Player, so at least it will get the
correct data from the duplicate, textual tags. Can you send us another small
file for testing?


Thanks again!


Carrie Hall
Conduits Technologies, Inc.
http://www.conduits.com/

[rusty]

Fixed in RC4. Thx.

-Rusty

[tobbbie]

Hi Rusty,

...what will happen to the library and tags set incorrectly now. Do I need to recalculate all the gigabytes again or will you migrate the wrong values in some way inside the libary (should be easy)? The option to synchronize library to tags should then allow to update all mp3 without a rescan as well.
My CPU would really like that - it was sweating for days until everthing was calculated..

thanks
tobbbie

[rusty]

The changes are small, but if you want to do them your machine will have to sweat

-Rusty

[tobbbie]

Hi rusty,

...you tell me that the wrong encoding of the peak value that you did (and stored in the database?) cannot be corrected within Mediamonkey and written back in the correct format?
Having access to the database directly this would be VERY EASY for you to do even without touching the mp3 files at all. Can you supply me help how I could do this conversion to the database - if it has to done at all?
Or is it only the storage in the mp3 tags that is done incorrecty?
If so - will the "synchronize tags" function rewrite the volume tags correctly to the mp3 - without having to recalculate again?

bye
tobbbie


P.S.: I meant my CPU would NOT like that ...

[jiri]

Actually yes, it's possible to fix this without re-calculating all files, just update tags of mp3 files and it should be ok then.

Jiri

[tobbbie]

Hi jiri,

...thanks for setting this straight, so only the tags enconding in the mp3s need to be updated - not new calculated.

bye
tobbbie