IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
MB COMAND: large AAC file playback problem, large AAC files cannot be played
Pete7874
post Sep 17 2012, 18:04
Post #1





Group: Members
Posts: 19
Joined: 5-January 12
Member No.: 96263



The wife's car is a 2008 Mercedes C300 with the COMAND multimedia/navigation system. According to the owner's manual, it'll play MP3 and AAC/M4A files.

However, when trying to play AAC files, I noticed that larger files will not play. For example, a 10 MB AAC file will play, but a 25 MB file will not. Such limitation does not exist for MP3 files.

I've got 1-2 hour long mixes that I often convert to AAC for portable players since even down at about 128 kbps AAC files sound very good but take up significantly less space. Alas, the COMAND will not read these.

When I contacted MB about it, they stated that the reason why these larger AAC files will not play is because of a small internal cache. While this does sound like a believable explanation, I wonder why this "small internal cache" is still big enough to play very large MP3 files, but not big enough to play large AAC files? I'm guessing it has to do with the way the COMAND reads AAC files... maybe it tries to load the entire file into cache before playing it as opposed to loading it a few frames at a time like may be the case with MP3 files? Even the cheapest smartphones out there will properly play large AAC files these days, so this is a bit weird.

FYI, I am using the Nero AAC encoder, but I also tried FhG with the same result.

Anyway, this is just an FYI more than anything else, but if someone can provide some insight into how an AAC file is typically read/processed by a player that might explain the above issue, I'd be thankful.

This post has been edited by Pete7874: Sep 17 2012, 18:05
Go to the top of the page
+Quote Post
C.R.Helmrich
post Sep 17 2012, 20:11
Post #2





Group: Developer
Posts: 690
Joined: 6-December 08
From: Erlangen Germany
Member No.: 64012



In theory, you need less than one second of cache to play (HE)AAC files, so either Mercedes use a terrible AAC decoder implementation which - as you suspected - reads the entire file into memory before decoding, or the problem is related to tagging and might be fixable as described here.

Chris


--------------------
If I don't reply to your reply, it means I agree with you.
Go to the top of the page
+Quote Post
Pete7874
post Sep 17 2012, 21:43
Post #3





Group: Members
Posts: 19
Joined: 5-January 12
Member No.: 96263



Thanks. I'll try optimizing the MP4 layout and see what happens.
Go to the top of the page
+Quote Post
Pete7874
post Sep 18 2012, 03:19
Post #4





Group: Members
Posts: 19
Joined: 5-January 12
Member No.: 96263



Well, just tried it. No go.
Go to the top of the page
+Quote Post
saratoga
post Sep 18 2012, 03:32
Post #5





Group: Members
Posts: 5047
Joined: 2-September 02
Member No.: 3264



QUOTE (Pete7874 @ Sep 17 2012, 13:04) *
When I contacted MB about it, they stated that the reason why these larger AAC files will not play is because of a small internal cache. While this does sound like a believable explanation, I wonder why this "small internal cache" is still big enough to play very large MP3 files, but not big enough to play large AAC files? I'm guessing it has to do with the way the COMAND reads AAC files... maybe it tries to load the entire file into cache before playing it as opposed to loading it a few frames at a time like may be the case with MP3 files?


MP4 seektables are complicated and can be very large for long files. If a device has limited memory it may not be able to play long AAC files.

MP3 does not use the same type of seek tables, so there is no limit on how long MP3 files can be.
Go to the top of the page
+Quote Post
Pete7874
post Sep 18 2012, 04:16
Post #6





Group: Members
Posts: 19
Joined: 5-January 12
Member No.: 96263



QUOTE (saratoga @ Sep 17 2012, 20:32) *
MP4 seektables are complicated and can be very large for long files. If a device has limited memory it may not be able to play long AAC files.

Do MP4 files with higher bit rates have larger seek tables?

The reason I ask is that if I start with the same 27-minute long source file and then create two MP4 files out of it:
1) 48 kbps, about 10 MB in size
2) 128 kbps, about 25 MB in size

Then COMAND will play file (1), but not file (2).

Go to the top of the page
+Quote Post
saratoga
post Sep 18 2012, 05:13
Post #7





Group: Members
Posts: 5047
Joined: 2-September 02
Member No.: 3264



QUOTE (Pete7874 @ Sep 17 2012, 23:16) *
QUOTE (saratoga @ Sep 17 2012, 20:32) *
MP4 seektables are complicated and can be very large for long files. If a device has limited memory it may not be able to play long AAC files.

Do MP4 files with higher bit rates have larger seek tables?

The reason I ask is that if I start with the same 27-minute long source file and then create two MP4 files out of it:
1) 48 kbps, about 10 MB in size
2) 128 kbps, about 25 MB in size

Then COMAND will play file (1), but not file (2).


Not sure how its handled in practice. I suppose you'd have to dig into the spec to see how the tables are likely to allocated.
Go to the top of the page
+Quote Post
benski
post Sep 18 2012, 17:36
Post #8


Winamp Developer


Group: Developer
Posts: 670
Joined: 17-July 05
From: Brooklyn, NY
Member No.: 23375



QUOTE (Pete7874 @ Sep 17 2012, 23:16) *
QUOTE (saratoga @ Sep 17 2012, 20:32) *
MP4 seektables are complicated and can be very large for long files. If a device has limited memory it may not be able to play long AAC files.

Do MP4 files with higher bit rates have larger seek tables?

The reason I ask is that if I start with the same 27-minute long source file and then create two MP4 files out of it:
1) 48 kbps, about 10 MB in size
2) 128 kbps, about 25 MB in size

Then COMAND will play file (1), but not file (2).


The seektable could be half the size if the stsz table can use 1 byte per entry instead of 2. But realistically, I think they are the same size. The code is likely trying to store the entire file into RAM to make parsing easy.

It is definitely bad programming, but as an aside (and a bit of a rant). This is the downside of the design of putting codec data inside a tree-based container (e.g. MP4, MKV). You can't just parse the "header" and assume that the remaining portion of the file is codec data, you might have legitimate container data after the codec data.
Go to the top of the page
+Quote Post
saratoga
post Sep 18 2012, 19:12
Post #9





Group: Members
Posts: 5047
Joined: 2-September 02
Member No.: 3264



QUOTE (benski @ Sep 18 2012, 12:36) *
The seektable could be half the size if the stsz table can use 1 byte per entry instead of 2. But realistically, I think they are the same size. The code is likely trying to store the entire file into RAM to make parsing easy.


Very unlikely. This is a car stereo, not a PC. It probably has 1-2MB of RAM. If it tried to buffer everything to RAM, it wouldn't work with files over 10 seconds.

Its probably just exhausting the available heap space trying to parse the seek table. This is a common problem with MP4 files on portable devices. With anything under 8-16MB you're likely to have problems.

QUOTE (benski @ Sep 18 2012, 12:36) *
It is definitely bad programming, but as an aside (and a bit of a rant). This is the downside of the design of putting codec data inside a tree-based container (e.g. MP4, MKV). You can't just parse the "header" and assume that the remaining portion of the file is codec data, you might have legitimate container data after the codec data.


Yes this has been a regular annoyance for rockbox as well. AACLC + HE tables can easily take up half a MB. Then on top of that you have to story an arbitrary amount of metadata just to parse the file. Fine for a PC with dynamic memory, not so fine for an embedded device where everything is allocated at start up (if extra memory is available at all).
Go to the top of the page
+Quote Post
Pete7874
post Sep 18 2012, 20:22
Post #10





Group: Members
Posts: 19
Joined: 5-January 12
Member No.: 96263



QUOTE (saratoga @ Sep 18 2012, 12:12) *
QUOTE (benski @ Sep 18 2012, 12:36) *
The seektable could be half the size if the stsz table can use 1 byte per entry instead of 2. But realistically, I think they are the same size. The code is likely trying to store the entire file into RAM to make parsing easy.


Very unlikely. This is a car stereo, not a PC. It probably has 1-2MB of RAM. If it tried to buffer everything to RAM, it wouldn't work with files over 10 seconds.


It's not a PC, but I'd compare it more to a smartphone rather than a car stereo. It handles navigation, voice recognition, DVD playback, phone over bluetooth, etc.

Which is actually an interesting thing - if it can play a DVD movie, isn't the audio track coded in something similar to AAC (AC3)? So it can play it as part of a video, but not alone??

FYI, COMAND uses a flavor of QNX as its operating system.
Go to the top of the page
+Quote Post
benski
post Sep 18 2012, 21:08
Post #11


Winamp Developer


Group: Developer
Posts: 670
Joined: 17-July 05
From: Brooklyn, NY
Member No.: 23375



QUOTE (saratoga @ Sep 18 2012, 14:12) *
QUOTE (benski @ Sep 18 2012, 12:36) *
It is definitely bad programming, but as an aside (and a bit of a rant). This is the downside of the design of putting codec data inside a tree-based container (e.g. MP4, MKV). You can't just parse the "header" and assume that the remaining portion of the file is codec data, you might have legitimate container data after the codec data.


Yes this has been a regular annoyance for rockbox as well. AACLC + HE tables can easily take up half a MB. Then on top of that you have to story an arbitrary amount of metadata just to parse the file. Fine for a PC with dynamic memory, not so fine for an embedded device where everything is allocated at start up (if extra memory is available at all).


To continue the discussion. I find it amusing that after decades of dealing with media file formats, I think I still prefer the MP3 scenario of [Metadata][Container Info][Codec Data]. It allows the metadata to be easily edited without risking damaging delicate information, and it allows the codec data to be treated as a block that can be read and buffered with normal file I/O without constantly parsing boundaries (e.g. AVI). Obviously MP3 has the problem that the Container Info is hidden inside a valid MP3 frame (or not at all, for older encoders) and so the amount of data that can be stored is tiny. But this model is much easier to work with and has few downsides (notably, you can't tune-in midstream like MPEG-2 TS). It also makes things much easier for HTTP streaming. MP4 was never meant to be streamable, it's just been used that way (most implementations use progressive downloading to simulate streaming).

Sorry to hijack the topic, we can split if anyone wants to continue the discussion.

This post has been edited by benski: Sep 18 2012, 21:09
Go to the top of the page
+Quote Post
saratoga
post Sep 19 2012, 03:27
Post #12





Group: Members
Posts: 5047
Joined: 2-September 02
Member No.: 3264



QUOTE (Pete7874 @ Sep 18 2012, 15:22) *
QUOTE (saratoga @ Sep 18 2012, 12:12) *
QUOTE (benski @ Sep 18 2012, 12:36) *
The seektable could be half the size if the stsz table can use 1 byte per entry instead of 2. But realistically, I think they are the same size. The code is likely trying to store the entire file into RAM to make parsing easy.


Very unlikely. This is a car stereo, not a PC. It probably has 1-2MB of RAM. If it tried to buffer everything to RAM, it wouldn't work with files over 10 seconds.


It's not a PC, but I'd compare it more to a smartphone rather than a car stereo. It handles navigation, voice recognition, DVD playback, phone over bluetooth, etc.

Which is actually an interesting thing - if it can play a DVD movie, isn't the audio track coded in something similar to AAC (AC3)? So it can play it as part of a video, but not alone??


AC3 is an extremely simple compression format. Its basically an MDCT codec stripped down to almost nothing. The rockbox decoder version takes about 70KB (not counting output buffer) and could probably be stripped down further. As for how much your device has, its hard to say. QNX runs on some really ancient hardware as well as PC class devices and everything in between. On top of that, the audio decoder may be some separate DSP with access to only some fixed memory. So your guess is as good as mine smile.gif


QUOTE (benski @ Sep 18 2012, 16:08) *
QUOTE (saratoga @ Sep 18 2012, 14:12) *
QUOTE (benski @ Sep 18 2012, 12:36) *
It is definitely bad programming, but as an aside (and a bit of a rant). This is the downside of the design of putting codec data inside a tree-based container (e.g. MP4, MKV). You can't just parse the "header" and assume that the remaining portion of the file is codec data, you might have legitimate container data after the codec data.


Yes this has been a regular annoyance for rockbox as well. AACLC + HE tables can easily take up half a MB. Then on top of that you have to story an arbitrary amount of metadata just to parse the file. Fine for a PC with dynamic memory, not so fine for an embedded device where everything is allocated at start up (if extra memory is available at all).


To continue the discussion. I find it amusing that after decades of dealing with media file formats, I think I still prefer the MP3 scenario of [Metadata][Container Info][Codec Data]. It allows the metadata to be easily edited without risking damaging delicate information, and it allows the codec data to be treated as a block that can be read and buffered with normal file I/O without constantly parsing boundaries (e.g. AVI). Obviously MP3 has the problem that the Container Info is hidden inside a valid MP3 frame (or not at all, for older encoders) and so the amount of data that can be stored is tiny. But this model is much easier to work with and has few downsides (notably, you can't tune-in midstream like MPEG-2 TS). It also makes things much easier for HTTP streaming. MP4 was never meant to be streamable, it's just been used that way (most implementations use progressive downloading to simulate streaming).

Sorry to hijack the topic, we can split if anyone wants to continue the discussion.


Downside of Mp3 is that seeking in long files is very inaccurate though. FWIW, I always like the ASF way actually, where you don't even need a table. Just a bunch of fixed size packets each with a time stamp. Lets you seek 100 hours into the future with millisecond accuracy knowing just the bitrate and packet size.
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd October 2014 - 21:25