The commit logs go into some detail on my analysis of the issue. I am not familiar enough with the existing code base (or mp3 format in general) to know if this is a good fix or what else I may have broke. It should be a useful reference for the issue anyway.
One limitation of the fix (or maybe this limitation always existed in some form) is for how it handles bad data. For example the ffmpeg_64k_cbr_corrupt.mp3 file will generate the following warning:
Unknown data before synch (ID3v2 header ends at 45, then 390 bytes garbage, synch detected at 435)
But in actual fact not all of that 390 bytes is garbage, part of that is the valid "Info" frame.
This PR also includes a second commit that is only loosely related to the issue but is something I came across while debugging it.
If any of this looks close to usable I am happy to make further refinements based on feedback or drop the second commit from the PR entirely.
This is a potential fix for #287.
The commit logs go into some detail on my analysis of the issue. I am not familiar enough with the existing code base (or mp3 format in general) to know if this is a good fix or what else I may have broke. It should be a useful reference for the issue anyway.
One limitation of the fix (or maybe this limitation always existed in some form) is for how it handles bad data. For example the ffmpeg_64k_cbr_corrupt.mp3 file will generate the following warning:
But in actual fact not all of that 390 bytes is garbage, part of that is the valid "Info" frame.
This PR also includes a second commit that is only loosely related to the issue but is something I came across while debugging it.
If any of this looks close to usable I am happy to make further refinements based on feedback or drop the second commit from the PR entirely.