search

aadsm / jsmediatags

Media Tags Reader (ID3, MP4, FLAC)
Other
748 stars 128 forks source link

Offset ... hasn't been loaded yet #58

Closed wol-soft closed 7 years ago

wol-soft commented 7 years ago

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

aadsm commented 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.

screen shot 2017-07-08 at 9 04 02 am

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.

wol-soft commented 7 years ago

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.