[X] Changing cover on Samba share results in invalid frame headers

Hi all

when I introduce, change or delete a cover in mp3 files on a linux-driven NAS, the file is corrupted, i.e. invalid frame headers lead to scratching noises when playing the file.

Some more information:

  • I have this problem for at least a year by now, i.e. it appears to be version independent.
  • This happens both if I access the network through wifi or wired connection.
  • The form of corruption is not systematic, i.e. applying the same change to different copies of one file results in different corruptions (i.e. at different positions in the file); sometimes (rarely), the cover is correctly placed in the file without corruption.
  • It happens on two different laptops I am using here (both Win7x64)
  • I dont have problems with other tag editors or any other programs accessing files on the NAS

The samba log on the server doesn't indicate any problems.

Output of mp3check, in case it helps:

05-machs einfach.mp3:
3056 bytes of junk before first frame header (*** THIS IS NOT NEW, IT'S IN THE FILE BEFORE CHANGING THE COVER ***)
valid id3 tag trailer v1.1 found
frame 94: invalid header at 0000f223 (0x5a26c3e8), skipping 1254 bytes
frame 301: invalid header at 0002f1f9 (0xf8a5b2c3), skipping 2508 bytes
frame 512: invalid header at 00050081 (0x6f04d29c), skipping 3135 bytes
frame 612: invalid header at 000601a5 (0x353a4796), skipping 627 bytes
frame 813: invalid header at 0007f057 (0x284df0fb), skipping 3135 bytes
frame 1331: invalid header at 000cf128 (0x88cef876), skipping 3135 bytes
frame 1542: invalid header at 000f0223 (0x69526185), skipping 1881 bytes
frame 1852: invalid header at 001200ab (0xfb7efa00), skipping 627 bytes
frame 1949: invalid header at 0012f0ab (0x80efdadf), skipping 2507 bytes
frame 2154: invalid header at 0014f081 (0x8b276665), skipping 2508 bytes
frame 2359: invalid header at 0016f057 (0x75596200), skipping 3135 bytes
frame 3824: invalid header at 00250057 (0x181a0b31), skipping 1254 bytes
frame 5286: invalid header at 003301a5 (0x42004829), skipping 2508 bytes

Please let me know if you need any further information.

Any help would be appreciated.

Thank you and best regards

Could you check the following:

run a check with mp3val over (some of) the corrupt files and repair them.
Run mp3val again and perhaps mp3diags to see that the files are clean.
Now add the cover (again) with Mp3tag.
Run mp3val/mp3diags to see if the files are now corrupt again.
BTW: IDV1.1 does not support covers.

Thanks for reading this! I dont know why mp3check exclusively mentions the IDv1.1 tag. The file contains a v2 tag as well. It could be that mp3check doesnt deal with v2 tags.

Anyway, i followed your suggestion to try to repair the corrupt file with mp3val.

First, it appears that mp3val successfully repairs the file: mp3val or mp3check dont find any errors in the "repaired" file. However, listening to the file reveals that errors remain and there is permanent damage to the file (i.e. the song skips).

Deleting and reintroducing a cover in this file is possible without creating new problems. The file is still damaged, of course (i.e. it still skips), but mp3check and mp3val doesnt find corrupt frames.

What does this tell you?

V1 tags are stored at the end of a file, V2 tags at the beginning.
Does M3diags show one V2 tag plus an offset where the audio data starts? Or just the V1 tag? (what does mp3tag say?)

What you hear is the tag data as apparently the player does not identify that part of the file as metadata - as the player probably can only cope with v1 tags.

If on the other hand mp3diags only reports a v1 tag in file that clicks then the start of the file is really damaged.

And further: if - after you have tagged the file with mp3tag - neither mp3diags not mp3val report corruption then it is not very likely that mp3tag is the culprit.

What I would try also: check a file that you have not yet tagged with mp3tag with both programs and see what they say. Hopefully, all files are ok. But if not ... it would mean that the errors crept in somewhere along your workflow.

Edit: I would like to add a link to this thread where some other poster complained about noise at the beginning of a file - perhaps you recognize something:
[X] Mp3tag corrupts every mp3 file after editing the tag .

I am not sure we are talking about the same problem. It seems to me that the problem is a different one than the one described in the linked thread.

I uploaded two mp3 files to illustrate the problem:

"06 - Grgoire Lourme - Fire Arrows And Shields.mp3" is the original (available for free download here: http://www.jamendo.com/de/list/a125563/cin...ic-soundtracks)

mp3check and mp3val don't find errors in the file. Mp3diag says that "No ID3v2.3.0" tag is found and that there is no APIC frame to store images in the original file.

"with cover 06 - Grgoire Lourme - Fire Arrows And Shields.mp3" is the file where I added a cover. You can easily see the corruption because the cover is not displayed correctly. And the corruption is audible (squeaking and skipping, mostly in the first 20 seconds).

Running mp3check on the corrupt file reveals invalid frame headers (see mp3check.log) and mp3val detects stream errors (mp3val.log). There are no audible improvements after the resynchronization with mp3val, i.e. squeaking and skipping continues.

Mp3diag diagnoses an invalid MPEG stream in the corrupt file. Interestingly, mp3diag says that there is still no ID3v.2.3.0 tag in the file. Something appears to go wrong when placing the cover (or the tag) in the file.

Unfortunately, it seems to be impossible to export mp3diag results. If you now how this is possible I would be happy to send those results too.

If I can provide anything else, please let me know.


mp3check.log (1.19 KB)

mp3val.log (3.28 KB)

What I can see is that the orginal file (06 ...) has a V2.4 tag.
The "with cover" file has a V2.3 tag.

I tried to add a cover to the original file and - naturally - the file is ok. Which is a pity as now I cannot reproduce the error.
Also, I noted that in comparison to the original the "with cover" file has far fewer fields...

Does the same thing happen if you tag the files on your local drive (and then transfer them to the samba server).

To be honest: I haven't got the foggiest.

Edit, amendment:
The new file has a sequence of printable characters followed by a 00 byte in the header. It looks as though someone adds an extra byte. But as the 00 is a delimiter for fields, this causes the damage.

Adding a cover on the local hard drive and transferring the file to the samba share works flawless.

The change from v2.4 in the original file to v2.3 in the file with cover appears to be normal, i.e. it also takes place if nothing goes wrong, e.g. if I put the cover into file on the local hard drive.

I will dig a little deeper. It's probably a problm resulting from an unfortunate combination of mp3tag and the server OS / samba configuration. There are unlimited possibilities, I guess.

If anyone has suggestions what I could try out, please let me know!

And thanks to you, ohrenkino, for your patient support.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.