Closed wol-soft closed 7 years ago
I found the issue, the ID3 frames in this mp3 file are indeed wrongly formatted.
For some reason the software used to generate them (MP3ext) inserts data at the end of the ID3 tag in a format that is not specified by the spec (it's not even a frame and the ID3 tag should be a collection of frames). It inserts the string "MP3ext V3.3.19(ansi)" multiple times after the last frame breaking the read logic.
I've searched around and found other ID3 reading software that has to explicitly accommodate for this error created by MP3ext. Apparently it's a well known problem:
MP3ext V3.3.17 places a non-compliant padding string at the end of the ID3v2 header. This is supposedly fixed in v3.4b21 but only if you manually add a registry key. This fix is not yet confirmed.
I can explicitly look out for this pattern and consider it as the end of the ID3 tag.
Maybe it's helpful to be alble to deal with the non-compliant padding to prevent the issue. As I said, a workaround is to rewrite the ID3 tags with another software like Winamp.
Thanks for your effords.
Hello,
I've experienced a similar behaviour as the following issues:
https://github.com/aadsm/jsmediatags/issues/29 https://github.com/aadsm/jsmediatags/issues/49
Object {type: "parseData", info: "Offset 315 hasn't been loaded yet."} 04 - Turn! Turn! Turn! (To Everything There Is A Season).zip
or
Object {type: "parseData", info: "Offset 274 hasn't been loaded yet."} 01 - Volunteers.zip
For my use case I have fixed the files by re-writing the ID3 tags with winamp. Maybe the files are helpful to debug the offset problems.
Thanks, Enno