GAPLESS Playback now in iPods - New!, Apple just announced today! GAPLESS playback...! Options

[nyaochi]

I also confirmed that iTunes v7.0.0.70 does attach the information for calculating accurate stream length to MP3 files.

Creating two WAVE files with 441000 samples (10 seconds) and 441001 samples (10 seconds + 1 sample), I encoded them to two MP3 files by using iTunes v7.0.0.70. I checked the MP3 files and noticed some differences in ID3v2.2 tags generated by the encoder.

[441000.mp3]
TT2: segment1
COM(eng): iTunPGAP=0
TEN: iTunes v7.0.0.70
COM(eng): iTunNORM= 0000121E 00000C71 00006417 00002D9A 000024A1 0000234E 0000827F 000085FB 0000023E 00000D43
COM(eng): iTunSMPB= 00000000 00000210 000007C8 000000000006BAA8 00000000 00026783 00000000 00000000 00000000 00000000 00000000 00000000

[441001.mp3]
TT2: segment1
COM(eng): iTunPGAP=0
TEN: iTunes v7.0.0.70
COM(eng): iTunNORM= 0000121E 00000C71 00006416 00002D9A 000024A1 0000234E 0000827F 000085FA 0000023E 00000D43
COM(eng): iTunSMPB= 00000000 00000210 000007C7 000000000006BAA9 00000000 00026783 00000000 00000000 00000000 00000000 00000000 00000000

Note that there're some differences in iTunNORM and iTunSMPB comment frames. The different values may represent the number of padded samples by the encoder.

As these MP3 files have 385 frames, the number of decoded samples will be 1152 * 385 = 443520 [samples] (without any handling for gapless playback). Assuming that the second and third values in iTunSMPB present the numbers of encoder delay and encoder padding in samples, I obtain the original sample length: 443520 - 528 (0x210) - 1992 (0x7C8) = 441000 [samples] = 10 [sec]. The forth value in iTunSMPB frame probably represents the original sample length since 0x6BAA8 equals to 441000 [samples]. I'm not sure how other values in these frames are used, but I hope this will be a good starting point to understand the mechanism of the gapless playback proposed by Apple.

I've been following this thread since it started. It seems that too many posts are primarily focused on gapless playback using iTunes7. The subject of this thread is not about iTunes7, it is about gapless plaback on iPods.

I agree with you, but we need to make sure whether if the necessary information for accurate stream length exists in the MP3 files encoded by iTunes. iRiver once claimed that they implemented gapless playback, but it was just the infamous gap (or silence) removal. Now that the necessary information is confirmed to be attached to MP3 files, we can celebrate the true gapless-playback only if someone with the new iPod experiments it on the hardware player.

[bhoar]

CUE is even more of a hack than 'conventional' gapless playback is. Stuffing all tracks in one file and then using a second file to split them again on playback is not a hack?

Isn't that essentially the definition of a redbook CD? A TOC + one continuous audio stream?

(Probably off-topic, and also a bit trite, sorry.)

-brendan

[Maurits]

CUE is even more of a hack than 'conventional' gapless playback is. Stuffing all tracks in one file and then using a second file to split them again on playback is not a hack?

Isn't that essentially the definition of a redbook CD? A TOC + one continuous audio stream?

(Probably off-topic, and also a bit trite, sorry.)

-brendan

Hhmmm, but CD's are oldfashioned crap.

[grommet]

I also confirmed that iTunes v7.0.0.70 does attach the information for calculating accurate stream length to MP3 files.

Just to make it clear: This only happens when iTunes 7 rips to MP3. It will not modify your existing MP3 files with these extra tags. (It didn't touch any of my LAME MP3 content.) It's a shame Apple didn't just write a LAME/Xing compatible header with enc_delay & enc_padding info when ripping to MP3... since that's as close to a "real" standard as you can get for MP3 gapless. Now we have more proprietary iTunes tags other players will probably ignore. I guess it doesn't matter. Who really uses the iTunes MP3 encoder?

This post has been edited by grommet: Sep 14 2006, 18:31

[AtaqueEG]

Almost everyone with an iPod and their mommas

[guruboolez]

LAME uses a method in which the correct track length is stored in metadata. With a compliant decoder, the track will be played to its original length everytime, perfectly.

The original length is indeed respected but the junction of two files isn't always smooth. As a consequence there's sometimes a small 'pop' when the player starts to read the following track. The problem is known and has been reported some times ago. LAME isn't alone in this situation: the same issue is reproducible with Nero AAC and WMAPro which are both supposed to be gapless. Vorbis and Musepack (1.15v only) aren't affected.

If you want to experience it by yourself, try with these small samples.


N.B. To be accurate, the existence of such pop doesn't question the 'gapless' status of these encoders. Simply because there's no gap (silence) between musical data, only a lack of harmony between the last samples of the initial file and the first samples of the subsequent one.

Pio2001 illustrated the problem in 2004:
http://www.hydrogenaudio.org/forums/index....post&id=390
More information:
http://www.hydrogenaudio.org/forums/index....showtopic=18211

This post has been edited by guruboolez: Sep 14 2006, 18:46

[Maurits]

Almost everyone with an iPod and their mommas

As far as I know iTunes has AAC encoding as default. Anyone just pressing 'Import CD' in iTunes will encode in AAC, not MP3

[greynol]

It will not modify your existing MP3 files with these extra tags. (It didn't touch any of my LAME MP3 content.)

I just verified this with my iPod's LAME MP3 content.

[hit_ny]

Isn't that essentially the definition of a redbook CD? A TOC + one continuous audio stream?

Exactly !!

Here's a simple test for gapless....Diskwriter

try saving to wav and compare the output
- of split traks + Lame gapless info vs playing the file continously.

Note the difference!

Stuffing all tracks in one file and then using a second file to split them again on playback is not a hack?

Obvious mistake, nothing is getting re-split.

Once you reach the designated track, its name changes, the stream is continous.

Maybe your ears won't catch the transitions, each time but they are there, not so with one continous stream. In fact someone just said they noticed very slight changes, that is proof enough for me that this is a best effort with mp3 that is not a gaples format to start with.

The workaround is to use CUE.

[AtaqueEG]

What I have noticed is that the time marker on the iTunes display kinda stops and "hesitates" at the last second.

This produces no audible effect, though. But it seems as though it was reading some tag or something.

[Maurits]

What I have noticed is that the time marker on the iTunes display kinda stops and "hesitates" at the last second.

This produces no audible effect, though. But it seems as though it was reading some tag or something.

I noticed that too. I think is because of the inaccurate time issues iTunes still has with MP3 VBR files, its prediction is often a few seconds too short.

[AtaqueEG]

In fact someone just said they noticed very slight changes, that is proof enough for me that this is a best effort with mp3 that is not a gaples format to start with.

The workaround is to use CUE.

OK, one more time: LAME MP3 is gapless, and has been for quite a while. It just needs a compliant decoder. Like your CUE sheet implementation-- if there is no compliant player that can read the CUE info and apply the necessary track "change points", it is completely useless.

But LAME's gapless implementation is clever and simple. Apparently, this time Apple went with something similar.

People wo "noticed differences" either used some unappropiate MP3 encoder/settings or a non-compliant decoder.

MP3 was not a gapless format to begin with. But since around 2003, it has been.

[kincaid]

I also confirmed that iTunes v7.0.0.70 does attach the information for calculating accurate stream length to MP3 files.

Creating two WAVE files with 441000 samples (10 seconds) and 441001 samples (10 seconds + 1 sample), I encoded them to two MP3 files by using iTunes v7.0.0.70. I checked the MP3 files and noticed some differences in ID3v2.2 tags generated by the encoder.

[441000.mp3]
TT2: segment1
COM(eng): iTunPGAP=0
TEN: iTunes v7.0.0.70
COM(eng): iTunNORM= 0000121E 00000C71 00006417 00002D9A 000024A1 0000234E 0000827F 000085FB 0000023E 00000D43
COM(eng): iTunSMPB= 00000000 00000210 000007C8 000000000006BAA8 00000000 00026783 00000000 00000000 00000000 00000000 00000000 00000000

[441001.mp3]
TT2: segment1
COM(eng): iTunPGAP=0
TEN: iTunes v7.0.0.70
COM(eng): iTunNORM= 0000121E 00000C71 00006416 00002D9A 000024A1 0000234E 0000827F 000085FA 0000023E 00000D43
COM(eng): iTunSMPB= 00000000 00000210 000007C7 000000000006BAA9 00000000 00026783 00000000 00000000 00000000 00000000 00000000 00000000

Note that there're some differences in iTunNORM and iTunSMPB comment frames. The different values may represent the number of padded samples by the encoder.

As these MP3 files have 385 frames, the number of decoded samples will be 1152 * 385 = 443520 [samples] (without any handling for gapless playback). Assuming that the second and third values in iTunSMPB present the numbers of encoder delay and encoder padding in samples, I obtain the original sample length: 443520 - 528 (0x210) - 1992 (0x7C8) = 441000 [samples] = 10 [sec]. The forth value in iTunSMPB frame probably represents the original sample length since 0x6BAA8 equals to 441000 [samples]. I'm not sure how other values in these frames are used, but I hope this will be a good starting point to understand the mechanism of the gapless playback proposed by Apple.

This analysis is correct. Additionally, the sixth value is the byte offset from the first audio frame to the 8th-from-last frame. This provides a resynchronization mechanism to restore a decoder's true sample number after a seek.

[nyaochi]

I also confirmed that iTunes v7.0.0.70 does attach the information for calculating accurate stream length to MP3 files.

Just to make it clear: This only happens when iTunes 7 rips to MP3. It will not modify your existing MP3 files with these extra tags. (It didn't touch any of my LAME MP3 content.)

Yeah. I didn't write this in the previous post, but I also confirmed that iTunes reads the MP3-Info header, where LAME stores the information for accurate stream length. I got gapless playback between two MP3 files encoded by LAME, but not if I modified (or broke the MP3-Info header), through a hex editor, the number of padded samples stored in the MP3-Info heder. This proves that iTunes 7 also supports the gapless playback with MP3-Info method, as well as iTunSMPB method.

Based on the posts in this thread, I guess (hope) that Apple implemented gapless playback with both MP3-Info and iTunSMPB methods in iTunes and the new iPod firmware. I don't like the idea of storing these information in ID3v2.2 since some tag editors may remove these frames accidentally (some tag editors cannot handle multiple comment frames properly). But Apple might hesitate to create MP3 files with MP3-Info header since the specification defines fields reserved specially for LAME (e.g., encoding flags, ATH type, noise shaping type, ...). Anyway, I think it's a great news that they supported MP3-Info method even if they introduced another method.

This post has been edited by nyaochi: Sep 14 2006, 19:14

[hit_ny]

And it this gapless info passes the diskwriter test ?

ie..compared WAVs are identical

This post has been edited by hit_ny: Sep 14 2006, 19:13

[Maurits]

It will not modify your existing MP3 files with these extra tags. (It didn't touch any of my LAME MP3 content.)

I just verified this with my iPod's LAME MP3 content.

That's odd compared to this users statement:
http://www.hydrogenaudio.org/forums/index....8231&st=29#


Edit: Or not.

I suppose tags are only written if iTunes had to analyse the encoder delay/padding itself. The values it finds are then stored in an ID3-tag. If iTunes could just rely on the data already in the MP3-info header put there by LAME it skips writing the tag because the data is already in the file.

This post has been edited by Maurits: Sep 14 2006, 19:21

[guruboolez]

In fact someone just said they noticed very slight changes, that is proof enough for me that this is a best effort with mp3 that is not a gaples format to start with.

The workaround is to use CUE.

And what about fixing the existing problem instead of jumping to another shaky solution like cuesheet?
MPC had the same issue: small glitchs on transition. An updated encoder fixed this issue and there's no complaint anymore.
Cuesheet is nice, but it supposes that you must upload to your iPod the full album, and that you can't delete from it some annoying tracks and to keep the most enjoying ones. Moreover, cuesheet doesn't work well with MP3-VBR. foobar2000 did it well, but this makes MP3 seeking much slower, even on 3GHz CPU... so let imagine the issue on a small iPod.

[hit_ny]

Sure but the beauty of cue sheet is it will play gapless on even the simplest mp3 player, or every mp3 player.

The only issue is you can't see the track names if the player is not equipped for this. Mjor issue on portable players but the sound is ok.

vs...gapless info with LAME header which only works with the right player & if it was encoded with this info in the first place.

Also the problem with a few bad tracks, well dont play the album then right

If its a gapless album to start with and you cut tracks off that are mixed in, the transition is sure to be jarring either way.

Regarding speed for seeking, i'm inclined to think its more of a HD issue than a CPU issue, the bottle neck is how fast it can read off the HD.

This post has been edited by hit_ny: Sep 14 2006, 19:30

[greynol]

It will not modify your existing MP3 files with these extra tags. (It didn't touch any of my LAME MP3 content.)

I just verified this with my iPod's LAME MP3 content.

That's odd compared to this users statement:
http://www.hydrogenaudio.org/forums/index....8231&st=29#

I just pulled a track from my ipod and looked at it with a hex editor. The file is exactly the same as it was before I put it on my iPod using iTunes. iTunes has never written anything to this file.

(Still lots of talk about gapless playback with iTunes and very little about gapless playback on iPods)

If iTunes could just rely on the data already in the MP3-info header put there by LAME it skips writing the tag because the data is already in the file.

Bingo!

[kincaid]

If iTunes could just rely on the data already in the MP3-info header put there by LAME it skips writing the tag because the data is already in the file.

Bingo!

iTunes only adds the tag to a track which IT encodes.

[greynol]

@hit_ny, quit trolling with the off-topic nonsense.

[hit_ny]

My intention is not to troll, i noticed the title gapless playback and stated my opinion on the topic.

If you want gapless, Apple's implementation is close but no cigar.

It's the only issue preventing me from getting an iPod atm.

This post has been edited by hit_ny: Sep 14 2006, 19:38

[greynol]

My intention is not to troll, i noticed the title gapless playback and stated my opinion on the topic.

If you want gapless, Apple's implementation is close but no cigar.

And this thing that isn't a cigar, is this fact or also your stated opinion?

[hit_ny]

Diskwriter test...

yes or no ?

I've yet to read about it.

record ouput from the iPod to WAV doing its "gapless" thing

..compare

This post has been edited by hit_ny: Sep 14 2006, 19:46

[Maurits]

If iTunes could just rely on the data already in the MP3-info header put there by LAME it skips writing the tag because the data is already in the file.

Bingo!

iTunes only adds the tag to a track which IT encodes.

Hhmm... I had my doubts about that and did a check. So far you seem right.

Where does iTunes store the values then? In the database? I suppose that makes sense because that's where the iPod needs the values as well since it won't read the tags on the files. Anyone notice any changes to the database structure?

This post has been edited by Maurits: Sep 14 2006, 19:47