Mp3check corrupting IDEv2 tags? FixHeaders kills files?

Bug #1348223 reported by Si Dedman on 2014-07-24
This bug affects 1 person
Affects Status Importance Assigned to Milestone
mp3check (Ubuntu)

Bug Description

This is a bug in progress as I'm not sure what's causing the problem.

1. I originally found these bugs by trying to copy loads of mp3s to an external drive and getting an input/output splicing error, and wrote down all those that didn't copy.
2. I found they weren't in my Rhythmbox library despite being present on my harddrive.
3. I tried mp3check which reported junk @ start & end and also truncated last frames, which I asked about (
4. I ran mp3checker in windows, which fixes various problems, on my entire library.
5. MP3 file was still not playable, didn't automatically show up in Rhythmbox library despite 'watch folders' on, and wouldn't play on double-click (however files which were previously seemingly dead & corrupted were fixed!)
6. Mp3checker in windows reported no problem, mp3val in windows reported no problem (for the known bad file)
7. Used mp3check in linux to fix junk @ start & end of file
8. file plays, hooray!
9. But: file only has IDEv2 tags. They're right (checking in Kid3) (other files in folder/album have IDEv1 & 2)
10. Rhythmbox & VLC don't see the v2 tags
11. Copying v2 to v1 in Kid3 works fine
12. Rhythmbox & VLC now see the v1 tags. But not the v2.
13. Stripping the V1 means RB & VLC now see no tags again. Why are the V2 tags invisible? Are they corrupted somehow?
14. Tried --fix-headers in mp3check
15. "bitrate switching 48 > 128, fixing header, syncing error (frame too long) skipping bytes"
16. Killed file: doesn't play.
17. Not sure what to do. Can restore specific file from backup... Did that, for all my problem files, and evidently the backups are clean so there are now no problems. However:

A. I don't know what the original problem was thus the efficient way to fix it in future;
B. I strongly suspect mp3check's --fix-headers function killed my file. Which feels like a bug.
C. I only found out about these duds by copying them all to an external HDD, which I'm not overly keen on doing again simply as a diagnostic... so I'm not sure whether there are MP3 on my drive which aren't in my Rhythmbox library because they have this problem, and I'm not sure how I'd find out, other than by happening to be listening to an album I know well and noticing a missing track. Any thoughts? Is there any search-like tool which will report how many mp3 files are in a recursed folder? At least that way that number should match my Rhythmbox library. Sort of...

Unfortunately I've now overwrite-restored all the dud files! I saved 3 which were problems but they seem to play in RB & VLC on double-click, with proper IDEv2s, so I don't know if they're problems...!

Thanks in advance. Like I say, this isn't a great bug report but it feels like there are potentially 2 mp3check bugs within this, so I figure it's worthwhile starting the reporting process in case that's true.

Si Dedman (si-dedman) wrote :

Relatedly, I was contemplating running through my entire library with:
"mp3check --cut-junk-start --cut-junk-end --recursive --only-mp3"
But i'm now concerned that it might be stripping IDEv2 frames etc.

"mp3check --recursive --only-mp3 --ign-junk-end --ign-junk-start --ign-bitrate-sw --log-file=mp3checklog.txt"
create a log of only mp3 files with:
128 byte TAG after last frame,
invalid frame header,
crc errors,
truncated last frames,
switching of constant parameters, such as sampling frequency?

Also: Given the existence of "--ign-bitrate-sw", would running "mp3check -e --fix-headers" over a VBR MP3 cause the problem in stage 15 of my main message above? If so, please could that be added to the manpage e.g.

              fix invalid headers (prevent constant parameter switching),
              implies -e, use with care. Incompatible with VBR files and will destroy them

Or potentially add an IF statement into the codebase along the lines of
"IF --fix-headers = TRUE
   IF file = VBR
   THEN --ign-bitrate-sw"
I don't know how to code really so this is just a guess, but you get the gist.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers