View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004038 | MMW v4 | Conversion/Leveling | public | 2007-11-27 19:25 | 2007-12-09 12:11 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.0 | ||||
| Summary | 0004038: Replay Gain tags in wrong format? | ||||
| Description | According to developer at conduits: The specification for RGAD tags states that the first four bytes (where it encodes the track's peak amplitude, from 0 to 1) should be written/read as a big-endian 32-bit float value. With MM3, RGAD peak values are definitely not big-endian floats (which is the standard) but are little-endian fixed point values. It seems to be 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. This is incorrect. We tested this with another track and matched it with the duplicate tag, under "TXXX replaygain_track_peak" with a value of 0.188782. The RGAD's hex value was 0x00 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). Having this value incorrect will mess up any calculations if "Clipping prevention" is enabled. The correct value it should be writing is roughly 0x3E 0x41 0x50 0x12, which is 0.188782 in big endian float. The specification says that these values should be float values, and 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. | ||||
| Additional Information | http://www.mediamonkey.com/forum/viewtopic.php?t=22865 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1115 | ||||
|
|
Fixed in build 1110. - Even though the specs aren't clear, I decided to go the route that (probably) most applications go (hard to say what's 'most', when there aren't many applications using RGAD at all). - In any case, it doesn't have any big impact on MM since it prefers TXXX ID3 frames for RG. |
|
|
Verified 1114 Values are now saved correctly, but values that were not saved correctly are not imported correctly and those tracks need to be Analyzed again as Clipping prevention do not work on those tracks as invalid Gain Triggers Clipping. Unfortunately I have already Analyzed all affected tracks in 1114 so I do not have sample one to send. |
|
|
Fixed in build 1115. - I slightly improved the algorithm of RGAD decoding in order to better recognize possible formats of numbers. That said, it should be ok even in the previous builds because MM prefers 'replaygain_track_peak' TXXX frame and so incorrect reading of RGAD shouldn't have any effect (and doesn't on tracks I tested). |
|
|
Verified 1115 (the fact that no regressions were introduced and that tags are readble in Winamp and Foobar). |
