iTunes gapless playback and Max' AAC's

Discuss the current and future development of Max.
Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

iTunes gapless playback and Max' AAC's

Post by Maurits » Tue Sep 26, 2006 3:12 pm

After a question I had a quick first look and Max generated AAC files appears not to have native iTunes gapless support. Max generated MP3's are gapless because LAME takes care of that.

For iTunes native gapless support there has to be an iTunSMPB field in the MOOV atom which states things like encoder delay and padding. This field is written there by iTunes after encoding. More info in this post by nyaochi and the followup by Bill Kincaid (one of the senior iTunes developers) with more background on the needed data. The post is about iTunes (not LAME) generated MP3's but similar formed data seems to be needed in the m4a metadata for AAC's.

Since encoder delay is supposed to be a static value and iTunes and Max share the same encoder Max could probably copy the value of encoder delay from any iTunes generated file, determining the other values is something else though. I'll have to have a closer look.

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Fri Nov 03, 2006 12:46 pm

Stephen, as you said in this topic on Hydrogen Audio, XLD seems to handle it.

Do you think it is terribly difficult to implement this in Max? It may be something to put in Max before the next Stable comes out because I fear the lack of it might keep people away from Max and keep ripping insecure with iTunes, as you can see in that topic.

User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Re: iTunes gapless playback and Max' AAC's

Post by sbooth » Fri Nov 03, 2006 2:35 pm

Maurits wrote:Since encoder delay is supposed to be a static value and iTunes and Max share the same encoder Max could probably copy the value of encoder delay from any iTunes generated file, determining the other values is something else though. I'll have to have a closer look.
Gapless for AAC is on the drawing board- hopefully I'll get to it this weekend. But as far as I know iTunes uses its own AAC encoder (not the Core Audio one) so I'm not sure that the encoder delay fields would be identical.

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Fri Nov 03, 2006 5:02 pm

I believe both CoreAudio and iTunes us the QuickTime encoder. If you look at iTunes encoded AAC files it will say in the encoder field the files was encoded with QuickTime encoder xxxx and on Windows you can't even install iTunes without installing Quicktime because iTunes needs it for encoding and decoding.

What I think is different is the route. iTunes bypasses CoreAudio and communicates directly with QuickTime, whereas most other software communicates just with CoreAudio.

If I can find the time tonight I'll encode a few files with XLD (which uses CoreAudio) and iTunes (which doesn't) to see if any differences in encoder-delay show up in the atoms.

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Fri Nov 03, 2006 7:57 pm

OK, I ran some tests...

First of all, I tested XLD's gapless implementation by running this test and it sounds flawless. That's good to know.

Second, XLD versus iTunes puzzles me. XLD gives all four files I tested the same encoder delay. The second Hex-number in the iTunSMPB field which is the number of samples encoder delay is constant (00000840) for XLD.
However, not only do the iTunes encoded files have a different encoder delay from the XLD ones, they differ from each other as well! Encoder delay (or at least the value in the iTunSMPB field) appears not be constant for iTunes. :shock:

I'm not quite sure what to think of this but it is not really important I suppose. The XLD implementation seems to work well and it has a constant encoder delay. This means Max could use the same mechanism.

Hope this helps! :)

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Mon Nov 06, 2006 11:36 pm

Regarding the use of encoders in OS X, I ran into an old topic and see what Stanley Kuo saysabout this.

User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Post by sbooth » Mon Nov 20, 2006 4:48 am

I've just checked in a first stab at implementing this, though it doesn't seem to work quite right. Any testing would be appreciated!

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Mon Nov 20, 2006 11:42 pm

Great! :)

I'm extremely busy for the next couple of days but will give compiling a shot as soon as I can and will thoroughly test it.

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Thu Nov 23, 2006 12:55 am

OK, I did some quick tests with four subsequent wavs that are gapless and this test again using build 1055.

Playback appears perfectly gapless in iTunes. :) What made you think it wasn't 'quite right' yet? Or have you fixed things since that comment?

The outcome of Max is the same as XLD and iTunes, the necessary data in the itunSMPB field is identical. The only difference is that XLD and iTunes write al hex in uppercase and Max in lowercase but it doesn't really seem to matter.


One other thing. Could it be that you either removed atom optimization on purpose or that it became dysfunctional by accident? Perhaps a result of writing the itunSMPB field after optimization instead of before which messes up the atom-order again. Is that an easy fix?

User avatar
sbooth
Site Admin
Posts: 2445
Joined: Fri Dec 23, 2005 7:45 am
Location: USA
Contact:

Post by sbooth » Thu Nov 23, 2006 2:52 am

I'm glad the gapless works- it did have some issues when I posted the comment about 'not quite right', but I believe I've fixed things since then.

As far as the atom optimization issue, I'm not sure why it would have stopped working. The iTunSMPB atom is written immediately after encoding finishes, in the encoder thread (along with an encoded by atom). The tagging and optimization are done later, in a different thread. I'll have to check into why it might have stopped working because if a file is being tagged it should also be optimized immediately after.

The one thing I'm not sure about is what the encoder delay value should be. I use 0x840 because that is what XLD uses. To be honest, I'm not even sure what encoder delay is. I need to do some research.

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Thu Nov 23, 2006 10:23 am

Thanks for introducing this gapless scheme in Max! :)

I'll have a further look to see if I can find anything strange happening in the optimization process.

As for encoder delay, surprisingly, Wikipedia has a nice article with some basic background information. Because encoder delay is a result of the way a typical encoder is constructed it is supposed to be a static value for each encode. It may differ between different encoders but not between tracks using the same encoder. That's why I was surprised to see iTunes giving these odd results.

I wouldn't worry about it too much, it appears to go well using 0x840 and the only reason I can see this value change is in OS X Leopard. If Apple did a complete encoder overhaul it may have a different delay as well. They probably won't though. Not unless they decide to encode to HE-AAC as that could be a big overhaul.

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Sat Nov 25, 2006 12:30 am

sbooth wrote: The one thing I'm not sure about is what the encoder delay value should be. I use 0x840 because that is what XLD uses. To be honest, I'm not even sure what encoder delay is. I need to do some research.
OK, something fell through and I had two hours to fill with just my laptop and no Internet.

I take back my earlier comment about iTunes' encoder delay being variable, don't know how I came to that conclusion. I've just inspected a few dozen files made by iTunes on their itunSMPB fields and all of them had an encoder delay of 0x840.

All other fields are the same as well. As I hardly understand any C I can't really figure out from the XLD source how it is done but it appears to be done right. What seems to help is the fact that it's AAC. If you look at the nyaochi and kincaid comments on HA.org on MP3 that is a lot harder with needing the 8th-from-last-frame to sync after seeks. Apparently AAC doesn't need it due to technical superiority (or something along these lines) because I never see this sixth value used in AAC itunSMPB fields.

I'd say this is a proper iTunes gapless implementation.

pwagland
Posts: 16
Joined: Tue Nov 28, 2006 11:29 pm

Post by pwagland » Wed Nov 29, 2006 5:51 am

sbooth wrote:I've just checked in a first stab at implementing this, though it doesn't seem to work quite right. Any testing would be appreciated!
I had a go at converting some flac files to AAC for my iPod. Under iTunes the files sounded perfect, that is I could detect no gap, however under the iPod there was a distinct (about 100ms) gap between the songs. I have marked all the songs as being gapless in iTunes, even though I understand that that should not make a difference.

I used max r1068 if it makes any difference.

Has anyone been able to get the max gapless files to play gaplessly under an iPod? If so, what magic was involved? :-)

Maurits
Posts: 117
Joined: Sun Jan 29, 2006 1:36 pm
Location: London, Europe

Post by Maurits » Wed Nov 29, 2006 11:53 am

That is strange. Since there is no difference between the gapless data produced by Max and by iTunes it shouldn't sound different.

If you let Max convert the FLAC files to Wav and then let iTunes convert the Wav's into AAC does it play perfectly gapless on the iPod?

What type of iPod is this? Which model and which generation? Which iPod firmware version? Which version of iTunes? I'd like to try it myself.

pwagland
Posts: 16
Joined: Tue Nov 28, 2006 11:29 pm

Post by pwagland » Mon Dec 04, 2006 9:12 pm

Maurits wrote:That is strange. Since there is no difference between the gapless data produced by Max and by iTunes it shouldn't sound different.

If you let Max convert the FLAC files to Wav and then let iTunes convert the Wav's into AAC does it play perfectly gapless on the iPod?

What type of iPod is this? Which model and which generation? Which iPod firmware version? Which version of iTunes? I'd like to try it myself.
Sorry for the delay in replying... work is hectic at the moment...

I agree that it is strange, and I find it really annoying... I blame the iPod, not Max, since it does play correctly under iTunes...

I will try the flac->wav->(iTunes AAC) as soon as I can and report back, those findings, in the meantime:

iPod: Version 1.2
iPod: Model PA147LL (5G 60GB)

These versions are reported from the iPod.

----

reporting back.

Converting FLAC -> ALAC with Max,

the ALAC plays gaplessly on the iPod.

Converting that ALAC to AAC with iTunes, the resultant AAC plays gaplessly on the iPod.

Converting the FLAC -> AAC with Max and there is a very small, yet still quite perceptible gap between the two tracks. It is "hiccup sized", yet still annoying once you get used to gapless ;-)

I have not tried converting ALAC to AAC using max, as at the moment I have run out of time for tonight... however if you really want me to, I can try that at a later date...

hope this helps,
Paul

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest