Long AAC files fail

[zajacattack]

Is there any hint as to why long AAC files won't play?

[Llorean]

Have you searched, I'm almost positive it's been explained before in general terms.

[zajacattack]

Yes, I can't seem to find what you are referencing.

[saratoga]

Lear has mentioned it in the past, but I can't find anything explaining why.  You may have to track him down and ask him directly.

Personally, I expect the answer is some variation of "faad sucks".

[linuxstb]

IIUC, it's nothing to do with faad, the issue is with the mp4/m4a container format, and Rockbox has its own written-from-scratch mp4 parser.

So whilst faad has many faults, we can't blame this one on it

[zajacattack]

So, it's most likely something in the parser?

[Llorean]

If I recall it's filesize based. So a test could be a few large mp4 files with ALAC and AAC audio in them, and see if they both fail at similar filesizes?

[zajacattack]

So, would the filesize limit thus apply to ALL formats, or just AAC?

[Llorean]

MP4 container. All formats that use it.

[Lear]

The MP4 container stores the size of each individual frame of the file (one frame is usually 1024 samples). This allows accurate seeking, but all this size information can be quite large. The current parser simply reads this table as is, and if the table is too large, it won't fit in memory, causing the playback to fail.

To complicate things a bit, this frame size table isn't enough to seek. There are actually 4 different tables involved (e.g., frames are grouped in chunks). The 3 other tables are usually small, but not always, which makes it difficult to say if a file will work or not given the file size or file time.

One way to fix this is to not just read the tables as is, but to merge individual frame sizes as they are read. This reduces the amount of memory required, at the expense of seek precision. It needs to be done at buffering time though, since you pretty much have to seek in the file in order to do it, given the memory constraints in Rockbox.

[zajacattack]

OK, so the problem IS in the MP4 container and in the design of how rockbox parses the files? If something could be done to allow larger tables than memory to be read, that would fix the problem, correct?

[Lear]

Yes, that's a correct interpretation of what I said.