I do a lot of aac file tagging most of my aac encoded with Nero and demux and remux in mp4 using case's foo_mp4 (dated Oct-17) for playback in iTunes.

After I masstagging (or just manual tagging) the files using fb2k 0.71 and 0.72b6, some of my files (a lot) are corrupted and foobar can't open it anymore (but iTunes can play some files).

I can reproduce the bug on some m4a file by:
- Edit some tags a couple of times (some of the files corrupt)
- Update the tag when the file still locked for playing (most of the files corupt)

I can provide sample files if needed.

I reported this earlier but got no response.

http://www.hydrogenaudio.org/forums/index....topic=13745&hl=

umm.. rufu experiance is very similar to mine.

http://www.hydrogenaudio.org/forums/index....howtopic=13534&

I found some mp4 file that corrupted almost everytime when it is tagged by foobar (0.71 and 0.72b6). If the devs need it, I will upload it. (But I think it's not neccessary.)

Devs have been unable to reproduce any of mp4 tagging issues but menno is working on new mp4 file library that hopefully solves issues everyone is experiencing.

I just uploaded sample mp4 file that is prone to tagging bug.
test.m4a (4.8MB)

Try to edit the tag (while it's still playing increase the chance of this bug).

I think this file was encoded with quicktime 6.3., demuxed, remuxed and optimized with foo_mp4.dll (17-Oct) on fb2k 0.7.1

I'm having the same issue when converting ape files to m4a. Itunes won't recognize the files and they will not play. Odd though, if I covert the files with Nero alone (from CD) it works fine. Only fails with foobar.

Can't reproduce with this file. Can you tell me what exactly you changed in the tag for this to happen?

Also the comment about editing while playing does not really make sense, because the file is then simply updated after playing has stopped, in the exact same way as would be done when not playing the file.

Menno

Umm...

Here is how I reproduce the bug.

- Open this file in foobar (7.2b8 with foo_mp4 dated Oct-17)
- Right click choose "Show file info"
- Mannually change the GENRE tag from "Thai" to "Pop" and the click "Update file"
- Try to play file again, if it still can play fine without error and try to change the tag again (I change GENRE from "Pop" to "Thai" again or whatever)
- The file will be corrupt after you cahnged the tag for 2-3 times (seems random)

Another easy way to corrupt the file is by clicking "Update file" rappidly in the file info window. (double click is enough)

Thank you for looking into this bug.

Ok, reproduced. Thanks a lot. I don't have much time right now, but I'll look into it tomorrow.

Does this only happen with the GENRE tag? If so, I can guess what the problem is

Menno

Should be fixed on new version, download.

Tried it and it's work.

Thanks. Now I'm confident to do masstagging with foobar again.

Is there anyway to fixed the corrupted file?

I ask this because the file that can't be played on foobar can be played fine in iTunes with all correct tags, so I think it's possible to fix the file.

Well, on the 1 file I managed to break, I could fix it like this:

Open the file in a hex editor and go to the end of the file. Somewhere around the end you'll see 4 bytes "free" select everything from 4 bytes BEFORE this "free" and delete it from the file. So the 4 bytes before these 4 bytes that say "free" should also be removed.

Menno

Thanks a lot, Menno Your suggestion is useful as before. Now I can fixed a lot of unplayable file without reripping.

I also found that a lot of playable mp4 file (maybe all files) that previously tagged with foo_mp4.dll version dated before 29-Oct has strange strings (4 bytes and then "free....etc..") at the end of the file.

MP4 tagging with new foo_mp4 (29Oct) does not have this weird strings. So I fears that my file may not fully compatible with mp4 file structures. Optimize the files seems to be the easiest way to get rid of it.

These "free" atoms are nothing to worry about. They are used to make editing mp4 file easier. For example when some atom is edited and the size has become bigger than before (which could happen when editing tags), instead of rewriting the whole file the exisiting atom is renamed to "free" and a totally new atom is written to the end of the file. Also if an atom has become smaller, the extra data that is left over is simply rewritten as a "free" atom, to prevent having to rewrite the whole file.

As you noticed something went wrong in this process with tag editing, but should be fixed now

You can remove these "free" atoms by using the "Optimise MP4 Layout" option.

Menno

Thanks again for clear explanation, it's the smart way to improve performance.