Rockbox

This is the bug/patch tracker for Rockbox. Click here for more information.

Quick links: Bugs · Patches · Rockbox frontpage

Tasklist

FS#11875 - Recent MediaMonkey Breaks Replaygain on low memory targets

Attached to Project: Rockbox
Opened by Martin Gallant (martyg) - Thursday, 13 January 2011, 20:11 GMT+2
Last edited by Andree Buschmann (Buschel) - Sunday, 30 January 2011, 21:24 GMT+2
Task Type Bugs
Category ID3 / meta data
Status Closed
Assigned To No-one
Player Type Another
Severity Low
Priority Normal
Reported Version Release 3.7.1
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Private No

Details

Also submitted in MediaMonkey forum:
http://www.mediamonkey.com/forum/viewtopic.php?f=7&t=54938

The latest version of MediaMonkey creates ReplayGain (volume analysis) tags which Rockbox 3.7 cannot understand.

Ref. These example files. http://www.goodbit.net/martyg/MM-Replaygain.zip
This is from the same source file, processed through v1297 and v1304 of MediaMonkey.
Rockbox recognizes the tag embedded in 1297.mp3 and adjusts level accordingly.
Rockbox cannot recognize the tag embedded in 1304.mp3.
This task depends upon

Closed by  Andree Buschmann (Buschel)
Sunday, 30 January 2011, 21:24 GMT+2
Reason for closing:  Fixed
Additional comments about closing:  Fixed with r29174.
Comment by Andree Buschmann (Buschel) - Thursday, 13 January 2011, 21:59 GMT+2
If you open both tracks with a hex-editor you can see that 1297 contains a tag with track_gain -6.85 dB and album_gain -6.51 dB. 1306 contains -6.85 dB for both album_gain and track_gain. This is what rockbox also reads and shows via "Show Track Info".

Tested with a build based on r28993.

Is this the issue you are a talking of? If so, rockbox works as expected.
Comment by Martin Gallant (martyg) - Friday, 14 January 2011, 19:39 GMT+2
Thanks for the prompt response to my issue.

I have done some more testing, and have discovered I can only reproduce this on my Sansa Clip v1.
I have tried a fresh install of 3.7.1 and r29051 and see this in both loads.

I cannot reproduce this issue on my Sansa Fuze v1 running v3.7.1. (I'm baffled)

To reproduce, I use WPS -> Context Menu -> Show Track Info
1297.mp3 shows gain information, 1304.mp3 does not
Comment by Andree Buschmann (Buschel) - Friday, 14 January 2011, 22:21 GMT+2
That was the missing link. I can now reproduce the error on a simulator build using "sansa clip".
Comment by Andree Buschmann (Buschel) - Friday, 14 January 2011, 23:16 GMT+2
Ok, issue is fully understood now. rockbox limits the amount of data it reads and parses from ID3 tags. For low memory targets like the Clip v1 (2 MB RAM only) this amount is limited to 300 bytes. For targets with more RAM this limit is set to 900 bytes. This limitation is done and needed to save memory.

Your new tagger creates the same overall length, but it resorts the position of data within the ID3 tag itself. In 1297.mp3 the replay gain data (to be more exact: its header) is placed in the first 300 bytes. In 1304.mp3 this data is placed _after_ the first 300 byte and will therefor be invisible for rockbox on low memory targets. The replay gain will still be recognized on targets with more RAM (e.g. your Fuze v1).

Option 1: Use the old tagger.
Option 2: Check whether the tagger can be configured to not save data to the ID3 tag which is not read by rockbox anyway (e.g. the whole "Jan. 12 (Bloomberg) -- Win Thin, a senior currencystrategist..." text which causes replay gain data to be shifted beyond the first 300 bytes)
Option 3: build rockbox by yourself and set "#define ID3V2_BUF_SIZE 900" in line 178 of /apps/metadata.h

So, this is not a bug but a consequence of an intentionally defined limitation.
Comment by Andree Buschmann (Buschel) - Saturday, 15 January 2011, 23:48 GMT+2
martyg, out of interest: Could you change the configuration of your tagger to make replay gain work for you again?
Comment by sideral (sideral) - Sunday, 16 January 2011, 01:27 GMT+2
The limitation of the amount of tag data that can be processed strikes me as a rather severe misfeature. I don't think it's OK to ask users to rearrange their tags to fit into a just a few bytes. Most users take great pains already to fix up their tags, and hitting them with another limitation will drive them away. (I actually speak from experience: My Sansa ClipV2 OF's problems with tags were my main motivator for looking for alternatives.)

Ideally, we should make an effort to support metadata of arbitrary size. It's OK to place a limit on each individual tag (for example, the album name has to fit into 300 bytes), but we should keep on looking for more data when the buffer is exhausted.
Comment by Andree Buschmann (Buschel) - Sunday, 16 January 2011, 09:10 GMT+2
Well, as long as there is no other parser solution implemented -- and that is not the case so far -- changing the tag itself is the easiest way to get replay gain running again for martyg. I am also not convinced that enlarging the buffer size should be done for the low memory targets.

I have added 2 other similar reports to "Related Tasks" which have basically the same issue.

If someone will make the effort to implement a more efficient parser this is of course fine for me as well :o)
Comment by Martin Gallant (martyg) - Sunday, 16 January 2011, 16:49 GMT+2
I have the luxury of owning more than one Rockbox capable player, so I will use my Fuze v1 as workaround for now,

I use MediaMonkey as a my Podcat/Playlist manager. I cannot find a way to work around this issue there.

IMO, it would be best if this restriction didn't exist in the first place.

Thanks for the attention to my issue. Rockbox is really a great product. I'm eagerly awaiting the Android version. :-)
Comment by Andree Buschmann (Buschel) - Sunday, 30 January 2011, 20:32 GMT+2
I needed a few hours to walk through the code in more detail. The size of id3v2buf[] is not used to _read_ the data, but to _save_ the data. The code reads id3-frame by id3-frame (e.g. title, artist, year, ...) and playces the read strings to this buffer. When reading from the attached files the buffer is immediately filled by the comments which are about 300 bytes long. All id3-frames after the comment cannot be saved in the buffer and are therefor dropped.

Easy solution: Limit the lenght for each id3 item.

The attached patch defines a maximum length for each item (60 bytes for low memory targets, 100 bytes for others). So, for the attached files this means that only the first 60/100 bytes of the comment are displayed by rockbox.

I am convinced such limitation makes sense and we could also use this to save some binsize again via reducing the buffer size again.
   id3_v01.patch (1 KiB) 
 apps/metadata.h         |    2 ++
 apps/metadata/id3tags.c |    6 ++++++
 2 files changed, 8 insertions(+)

Loading...