Strange file cannot be read or written

[sandreas]

The problem

I have an m4b file, where atldotnet cannot read or write any of the fields, that I am trying (Album, Title, AdditionalFields, etc.). It is one single file, very specific, but I did not see anything special about it.

• The file size is 367MB and unfortunately I cannot share it on github
• There is no logs, Save is called successfully without any issues
• Re-reading the file with atl does not show the before written tags

Is there any way to privately share the file and ensure that it'll gets deleted after investigating the problem? :-)

Environment

• ATL version: 4.7.0
• Linux Ubuntu 18.04 LTS

[Zeugma440]

First things first, did you check if it is read-only ? Did you try renaming it or putting it in another folder ?

If nothing works, you may send me the file over a 3rd party file sharing service (e.g. MEGA or Dropbox)

[sandreas]

Ok, permissions are not the problem I think. I'll send you the file, you can remove your data from comment above :-) Thank you very much.

[Zeugma440]

Got it, thanks !

ATL says in its logs moov atom could not be found; aborting read. moov is an essential atom describing the content of the file. It's the very first thing ATL looks for.

Here's what 3rd party tools do :

• VLC reads the audio properly but fails to detect any metadata, including chapters
• foobar2000 says the file is corrupted
• MediaInfo detects the audio, but no metadata either
• MP4 Explorer (old but handy tool) completely fails loading the file
• AtomicParsley is fine with how the file is structured and properly detects the moov atom, which is located at an unusual place, at the very end of the file, after 5 mdat atoms.

Atom ftyp @ 0 of size: 28, ends @ 28
Atom free @ 28 of size: 8, ends @ 36
Atom mdat @ 36 of size: 391856151, ends @ 391856187
Atom mdat @ 391856187 of size: 8, ends @ 391856195
Atom mdat @ 391856195 of size: 5113, ends @ 391861308
Atom mdat @ 391861308 of size: 8, ends @ 391861316
Atom mdat @ 391861316 of size: 8, ends @ 391861324
Atom moov @ 391861324 of size: 2178008, ends @ 394039332

Most MP4/M4A/M4B files I've seen do the opposite, which is writing the moov atom at the very beginning of the file, and then writing actual data. I'll see what can be done to adapt the code to the file you've sent.

[Zeugma440]

I think I found the core issue : your file has either been truncated, or badly edited.

The moov atom is detected by ATL, but it is declared with an incorrect size (its declared size goes beyond the actual file size), which explains why other softwares label the file as "corrupted".

ATL can ignore that and log a warning. I also have to make sure it writes a correct header.

[Zeugma440]

...on top of that, its udta atom is located inside the trak atom, which is legit but super rare as well (all files I've seen so far have their udta as a child of moov).

Any idea of which software has been used to tag that one ?

[sandreas]

I think I found the core issue : your file has either been truncated, or badly edited.

Wow, thank you. I already thought that something was wrong with the file. I created the file using m4b-tool, my personal wrapper for fdkaac, ffmpeg and mp4v2.

Any idea of which software has been used to tag that one ?

The file itself was created by ffmpeg with concat option, the files, that were concatenated were created by fdkaac and the tags of the final file were written by mp4v2. This usually works fine, but maybe in this case something went wrong.

This may have to do with the source files or the process of merging them. I'll rebuild the file with m4b-tool and see, if that happens again or if the file is fixed.

Thank you for investigating - I think there is no need to change atldotnet, unless you would like to make it even MORE robust, as it is.

I greatly appreciate your work and time :-)

[Zeugma440]

Awesome, thanks for your feedback.

I was about to report that ATL has been improved to be able to read metadata from such files. However, fixing files with corrupted headers is something else altogether, as the library has been designed to alter as little as possible from the source file.

In other words, the library can surgically insert metadata inside a corrupted file while maintaining its corrupted structure.

A "rebuild file" mode is feasible but would require a great deal of brand new code. I'd rather not dive into that if it's not absolutely required.

[sandreas]

I'd rather not dive into that if it's not absolutely required.

I like that we think alike about many things :-)