So after reading other posts in HA (in the Foobar forum, of course), I had to ask: Other than Foobar, what other MP3 players (software or hardware) actually support gapless playback (barring DSPs and the sort)? Why the heck not? And will they ever?! I'm so very happy with Foobar for doing this, but I feel all the more irritated listening to my albums on my portable MP3 player (or in Winamp for that matter) because I expect my songs to be gapless!
Other than Foobar, what other MP3 players (software or hardware) actually support gapless playback (barring DSPs and the sort)?
None.
Why the heck not?
Well, LAME header isn't a part of MPEG Layer 3 standard, for one.
But the main reason is that generally people just don't care.
And will they ever?!
foobar's mp3 decoder is open source and distributed under the BSD license, so other developers may implement it sometime... provided they get enough feedback from the irritated users
I'm so very happy with Foobar for doing this, but I feel all the more irritated listening to my albums on my portable MP3 player (or in Winamp for that matter) because I expect my songs to be gapless!
Most people don't give a flying xiph about gapless playback, so it's the last thing that hardware manufacturers will think about. I am not aware of any currently available hardware player that supports gapless playback for mp3... or even ogg vorbis, which is inherently gapless. Support for gapless playback of vorbis or flac is supposed to come with the next version of Rio Karma firmware.
1by1 ( http://www.rz.uni-frankfurt.de/~pesch/ (http://www.rz.uni-frankfurt.de/~pesch/) ) supports gapless playback and I think it did before foobar.
1by1 does not support gapless mp3 playback, I just tested 1.41. Please don't post false info.
Back on topic, in_mpg123 (http://www3.cypress.ne.jp/otachan/in_mpg123.html) for Winamp2/Winamp5 supposedly supports gapless MP3 playback in similar way to foobar2000 according to what I've read (can't verify at the moment).
Wasn't stock Winamp3 gapless?
Don't remember too well, it's been years since I touched WA.
Wasn't stock Winamp3 gapless?
Don't remember too well, it's been years since I touched WA.
"Gapless" as in "doesn't need to reopen output between tracks". 1by1 can do that too, as well as any half-decent player these days (actually Winamp2/5 needs output plugin side hack for that).
"Gapless playback" consists of two parts:
1) Gapless decoding - lossy formats like MP3 store audio data in frames, which can't store entire audio CD track without either truncating last samples or adding extra null samples (total length must be a multiply of frame size, being fixed at 1152 samples for MPEG-1 layer 3); MP3 also suffers from encoder/decoder delay causing the decoder to produce additional null samples at the beginning of decoded stream. In order to correct this problem, lossy-encoded file needs to store two additional numbers - amount of samples to remove at the beginning of stream, and amount of samples to remove at the end of stream, then the decoder needs to take these nubmers into account. That's what this thread is about. LAME 3.90 and newer can store gapless playback info in LAME headers, and some players (like foobar2000) can play those files without encoder-added null samples at the beginning/end of file.
Another way to workaround gapless decoding is to write a DSP that tries to guess amount of samples that needs to be removed, but that method is simply unreliable and generally useless since players reading LAME header info exist (as well as tools to manually add gapless playback info to MP3 files that don't contain it).
2) Gapless output - many (mostly old) players have a design flaw requiring them to reopen wave output device between tracks, producing audible pauses. Modern players such as Winamp3 and foobar2000 don't have this problem; Winamp2/5 has "gapless output plugins" that avoid reopening output at cost of other minor glitches (displayed playback position being ahead of actual sound, etc; they trick the player to start decoding next track while previous one is still being played).
SoundPlayer Lilith (http://www.project9k.jp/) makes gapless playback too.
But it doesn't have English version or any, except Japanese version.
BTW I don't use Lilith or in_mpg123 for gapless playback due to lack of the feature like
foobar's Fix MP3 header for non-LAME(or old LAME)-encoded mp3 files.
If anyone is interested in testing gapless mp3 playback of some player, I've uploaded some test samples.
http://foobar2000.org/gapless/part1.mp3 (http://foobar2000.org/gapless/part1.mp3) | http://foobar2000.org/gapless/part2.mp3 (http://foobar2000.org/gapless/part2.mp3)
Instructions: put both parts on playlist, play part1, part1=>part2 transition is supposed to be glitchless.
They're taken from Jarre's Second Rendez-vous; the track division is same as on original CD. I didn't tinker with them, they're straight output from lame.exe v3.90.3, --alt-preset standard -Y, transcoded from MPC.
Another way to test it, make a WAV, feed it to LAME, then decode the output MP3 back to WAV using your player, compare exact WAV lengths.
OK, I have uploaded some files.
part1_in_mpg123.flac (http://harashin.tripod.com/gaplesstest/part1_in_mpg123.flac)
part2_in_mpg123.flac (http://harashin.tripod.com/gaplesstest/part2_in_mpg123.flac)
part1_lilith.flac (http://harashin.tripod.com/gaplesstest/part1_lilith.flac)
part2_lilith.flac (http://harashin.tripod.com/gaplesstest/part2_lilith.flac)
Ugh... text/html, CR/LF translation. Can you please upload them zipped ? I get unplayable garbage.
Fixed
http://harashin.tripod.com/gaplesstest/gaplesstest.zip (http://harashin.tripod.com/gaplesstest/gaplesstest.zip)
Yup, confirmed. Both in_mpg123 and Lilith give correct results (exactly same length, no glitches).
1by1 does not support gapless mp3 playback, I just tested 1.41. Please don't post false info.
Back on topic, in_mpg123 (http://www3.cypress.ne.jp/otachan/in_mpg123.html) for Winamp2/Winamp5 supposedly supports gapless MP3 playback in similar way to foobar2000 according to what I've read (can't verify at the moment).
Under settings, audio there is a tick box for gapless output. I am using version 1.40. So this is not what it indicates itself to be and the seamless songs with no gap I hear are not gapless?
I read your other postings so it seems there is a pseudo gapless mode and a true gapless mode or what?
Fact is 1by1 uses less resources and when I am mutli-tasking like mad it plays back better than foobar. I hear foobar stop and start again with last bit of a song and then next song. Only when using lots of resources. 1by1 does not do that. Of course when not using up all my resources foobar sounds ok.
1by1 uses winamp plugins so its quite handy.
1by1 does not support gapless mp3 playback, I just tested 1.41. Please don't post false info.
Back on topic, in_mpg123 (http://www3.cypress.ne.jp/otachan/in_mpg123.html) for Winamp2/Winamp5 supposedly supports gapless MP3 playback in similar way to foobar2000 according to what I've read (can't verify at the moment).
Under settings, audio there is a tick box for gapless output. I am using version 1.40. So this is not what it indicates itself to be and the seamless songs with no gap I hear are not gapless?
Please actually read the topic (especially my long post explaining what gapless playback is) before replying to it... I did not manage to get 1by1 to play above test files correctly, therefore its mp3 decoder is not gapless. And yes, I did check "gapless output" checkbox.
You asked --
http://40th.com/w32/ (http://40th.com/w32/)
iPlay file player for the desktop. Features include a true 5-band equalizer with seven EQ presets, easy-to-use file selection and lots more. Plays MP3, Ogg, PCM, CD/DA, and GSM-610 formats (gapless option for all but GSM). Also available for Pocket PC 2002 & 2003.
- - - -
Perfectly gapless ogg, perfectly gapless mp3 (44100,stereo; no attempt on others), perfectly gapess CD/DA (and very battery friendly, yet still gapless).
This is re: iPlay v1.52.138.312 -- one single file, maybe 300 KB. Market spiel:
[further flood removed by moderation]
You asked --
http://40th.com/w32/ (http://40th.com/w32/)
....
Actually it seems like it is gapless, after having wasted 15 minutes of my time on trying to figure how to add my files to its playlist. Can't be bothered to verify lengths after decoding to WAV.
Seems like there is a very quiet (but noticeable) pop between tracks in the sample I posted, and it's not a fault of playback software (mismatching sample values after transcoding). I'll post a new sample later.
In answer to the original question, my Nomad Jukebox3 gives gapless playback. Every so often there are little hiccups and also I think it needs to be ripped on the Creative MP3 ripper that came with it (though I haven't tested this completely scientifically). I assume that the glitches come when it finds it too hard to completely fill in the frames or something, but it's basically solid.
Wasn't stock Winamp3 gapless?
1) Gapless decoding - lossy formats like MP3 store audio data in frames, which can't store entire audio CD track without either truncating last samples or adding extra null samples (total length must be a multiply of frame size, being fixed at 1152 samples for MPEG-1 layer 3);
It seems to me the most sensible way around this is to encode the whole album (or whatever sequence of tracks needs to be gapless) then split the mp3 file into tracks on frame boundaries. For the albums I have with gapless tracks the exact time of the split is not important in terms of ~1/100 second (roughly the average amount of gap due to mp3 frame boundary).
Are file splitters such as mp3directcut smart enough to split on frame boundaries?
umm,
as Peter stated, in_mpeg123 supports gapless playback. so is this a limitation of winamp 2 itself or rather a limitation of the FhG in_mp3 plugin?
or is gapless playback only possible with in_mpeg123 and the additional "buffer ahead on track change" option in your out_ds??
*slightly confused*
amano
umm,
as Peter stated, in_mpeg123 supports gapless playback. so is this a limitation of winamp 2 itself or rather a limitation of the FhG in_mp3 plugin?
or is gapless playback only possible with in_mpeg123 and the additional "buffer ahead on track change" option in your out_ds??
*slightly confused*
amano
Proper gapless playback in Winamp requires both in_mpg123 and "gapless" output plugin (configured not to reopen output between tracks, but without removing silent samples, since input plugin already does that without guessing exact number of samples to remove).
tnx for clarification, so I guess that MAD and FhG additionally need the remove silence option to be checked .?.
or can't gapless playing achieved with them at all?
EDIT: bad grammar
MAD and FhG would need something else (DSP or output) to remove silent samples, which is unreliable / uninteresting / etc (as original post in this topic states), since such solution needs amount of samples to remove to be guessed somehow (usually by analysing sound data). Also, if you decode an MP3 file from FhG or MAD inputs, exact length of decoded WAV wouldn't match original WAV length.
OK, thanks for the quick reply
It seems to me the most sensible way around this is to encode the whole album (or whatever sequence of tracks needs to be gapless) then split the mp3 file into tracks on frame boundaries. For the albums I have with gapless tracks the exact time of the split is not important in terms of ~1/100 second (roughly the average amount of gap due to mp3 frame boundary).
Are file splitters such as mp3directcut smart enough to split on frame boundaries?
That would not do it.
WAV files ripped from CD are already cut to frame boundaries (Red Book standard).
The gap in MP3 playback/decoding is introduced by encoder/decoder delay (kind of like an offset). The only way around this is the foobar2000 method: the "real" length of the source file is stored in the MP3 header. Then, a properly tuned decoder (such as foobar's) can play the file for just as long as the header tells it to, thus providing a resulting decoded file that matches the exact, already-cut-to-frame-boundaries length of the original file, which is obviously, "gapless".
Cutting the MP3 would do no good, as there will be always a silence introduced upon decoding.
Thank you for your explanation, AtaueEG, now I can stop beating my head against the wall trying to get rid of gaps in my opera rips. I guess it will be one track per act.
But this leads to another question. Do you know of a ripper where I can select multiple tracks and rip to a single wav? EAC seems to be to individual tracks or the image of the whole disk (unless I'm missing something)
EAC.
Action-->Copy Range-->You will be presented with a "seekbar" with track markers representing the whole CD, set the beggining and end of your rip and off you go!
(altough this only works for subsequent tracks --joining 1 with 2 with 3, but not 1 with 3--, joining non subsequent tracks is a little tricky)
But this leads to another question. Do you know of a ripper where I can select multiple tracks and rip to a single wav?
dbpoweramp's ripper has a setting for that, but I haven't tried it.
Well, it seems I opened up an old can of worms here but oh well! Looks like I'll be sticking with Foobar for my listening pleasure. But I am curious about the statement about the Creative player having some kind of (proprietary?) gapless option. I'd be interested in finding out just what they did to make their mp3s gapless, although it's questionable whether what they've done is compatible with any other player. Would anyone be interested in experimenting/testing this?
Proper gapless playback in Winamp requires [...] "gapless" output plugin (configured not to reopen output between tracks, ...
Just for completeness, Winamp 2 have had built in gapless output (WaveOut and DirectSound out plugins have been turned gapless) since two or three release now.
Proper gapless playback in Winamp requires [...] "gapless" output plugin (configured not to reopen output between tracks, ...
Just for completeness, Winamp 2 have had built in gapless output (WaveOut and DirectSound out plugins have been turned gapless) since two or three release now.
Yup, but what they do is abuse of Winamp's API (tricking the player to start decoding next track while previous is still playing), causing minor glitches (though ability to configure decode-ahead time makes the glitches hard to notice when configured properly).
Seems like there is a very quiet (but noticeable) pop between tracks in the sample I posted, and it's not a fault of playback software (mismatching sample values after transcoding). I'll post a new sample later.
Well, zZzZzZz hasn't posted his new sample yet, so I'll post the sample
I always use to test gapless playback.
I use the transition between the songs "The Happiest Days Of Our Lives" and "Another Brick In The Wall - Part 2" from "The Wall" by Pink Floyd.
Here are the files:
01.mp3 (http://users.skynet.be/bk343709/Audio/01.mp3) - The last 10 seconds of "The Happiest Days Of Our Lives"
02.mp3 (http://users.skynet.be/bk343709/Audio/02.mp3) - The first 10 seconds of "Another Brick In The Wall - Part 2"
They should play perfectly gapless on foobar2000 or any other player that properly supports gapless MP3 playback.
"They should play perfectly gapless on foobar2000 or any other player that properly supports gapless MP3 playback."
Tried this on the two players I use fairly often on my machine:
Windows Media Player 9 = Perfect playback, gapless
Musicmatch 8.1 = Tiny hiccup between the two tracks (1/10 of a second?)
And as a comment to someone earlier re: Creative Jukebox 3 = Gapless, as well
Unfortunately XMMS isn't gapless. (w/o nasty hacks)
It is that way just because API is very similar to Winamp 2.
Windows Media Player 9 = Perfect playback, gapless
(...)
And as a comment to someone earlier re: Creative Jukebox 3 = Gapless, as well
Strange... are you sure you're not using crossfading ?
I have a ~2 seconds gap with Windows Media Player 9.
OK, without realizing it, I had crossfading turned ON with WMP9 (with 0 seconds as the gap). So I turned it OFF, but still get gapless playback (no interruption in the stream) but a tiny "click" between tracks (i.e., I'd know there was a track break there because of the click).
Don't know why the other guy would be getting a 2-second gap!
but still get gapless playback (no interruption in the stream) but a tiny "click" between tracks (i.e., I'd know there was a track break there because of the click).
Then it is not "gapless".
Gapless means a completely seamless transition.
No click or anything.
A gap does not have to be long to be bothersome.
In fact, almost all current players will play the tracks almost inmediately but with that tiny "click". Even the hardware ones.
Don't know why the other guy would be getting a 2-second gap!
OK, first, the "other guy's" name is Sebastian.
The problem with the 2 second gap may be caused by my wonderful PC which is a Pentium II with 333 MHz.
I have just tested on a friend's PC (with 2400+) and it happens the same thing you said - only a small click between the tracks.
Winamp 2 (and Winamp 5 beta) will do gapless playback with the right output plugin. There are a number of plugins that don't work, but two that do work almost flawlessly are "Gapless Audio Output" (out_nogap.dll) and "MP3Splice" (out_mp3splice.dll). As someone else noted, most people don't really care about gapless playback. It's an issue mainly for opera, Mahler symphonies, etc.
ltoth
You asked --
http://40th.com/w32/ (http://40th.com/w32/)
....
Actually it seems like it is gapless, after having wasted 15 minutes of my time on trying to figure how to add my files to its playlist. Can't be bothered to verify lengths after decoding to WAV.
Not sure how to post here. Looks like this is the right box. So, you could not add files? There's built-in help so you could do it that way, or tap/click
[FS] file system
Then either type in the directory (wildcards, including in directory paths themselves, work) in case it's another drive, or move around the treeview picker. You don't need to do a playlist, but tap/click
[DIR] (changes to PL) APPEND/REPLACE at the bottom to ... well?
if you wanted to. The file pl/playlist.txt, in the package, explains it, though it's not hard if you press the little [?] at the top right since the built-in help is complete in every detail. Very powerful stuff, and very easy, but you have to have at least an inkling of what you're doing. Consider that I never could get FB to sort the way I wanted files to play. Not in 15 minutes, not in 15 hours (I suppose it is possible). I wound up having to rename the files...or some trick that I forget now... to get them to play the order I wanted. Reminds me of winamp, with the myriad preferences. EQ could be better, too. And really, Peter (hope I got that right!), you come off like a, well, you know -- not a very nice guy. Which reminds me of a Styx tune, it goes something like this:
Fooling Yourself (The Angry Young Man)
Written by Tommy Shaw
Lead Vocals by Tommy Shaw
You see the world through your cynical eyes
You're a troubled young man I can tell
You've got it all in the palm of your hand
But your hand's wet with sweat and your head needs a rest
And you're fooling yourself if you don't believe it
You're kidding yourself if you don't believe it
How can you be such an angry young man
When your future looks quite bright to me
How can there be such a sinister plan
That could hide such a lamb, such a caring young man
You're fooling yourself if you don't believe it
You're kidding yourself if you don't believe it
Get up, get back on your feet
You're the one they can't beat and you know it
Come on, let's see what you've got
Just take your best shot and don't blow it
You're fooling yourself if you don't believe it
(But don't take it too personally -- it's just the way it looks from here.)
It's an issue mainly for opera, Mahler symphonies, etc.
Also any album that's sequenced together with no or few gaps between tracks (concept albums, for instance) and don't forget DJ mixes!
hmm, I tested foobar last night w/ the beatles sgt. pepper's lonely hearts club band, more specifically the first 2 tracks which very clearly flow into each other. The gap is almost gone, but I could still hear a very tiny miniscule one. It's still worlds better than winamp though, so I'm going to stick with foobar
btw, do any of the hd-based portables support gapless?
The Rio Karma supposedly does but I haven't been seen any verification of it from Karma users.
The Rio Karma supposedly does but I haven't been seen any verification of it from Karma users.
Ogg Vorbis playback should be 100% gapless, MP3 playback should be "almost" gapless.
Check here...
http://www.riovolution.com/forums/viewtopic.php?t=876 (http://www.riovolution.com/forums/viewtopic.php?t=876)
... and check the
last couple of posts of this thread:
http://www.riovolution.com/forums/viewtopi...?t=181&start=75 (http://www.riovolution.com/forums/viewtopic.php?t=181&start=75)
It looks like they're planning to implement foobar2000's method for gapless playback in a future firmware revision:
http://www.riovolution.com/forums/viewtopic.php?t=1167 (http://www.riovolution.com/forums/viewtopic.php?t=1167)
I can stop beating my head against the wall trying to get rid of gaps in my opera rips. I guess it will be one track per act.
You're right, Nolonemo, opera is the biggest problem. But I have thousands of LAME VBR encoded opera tracks that playback without gaps using Winamp 2 (and now Winamp 5) and the output plugins mentioned previously, "Gapless Audio Output" (out_nogap.dll) and "MP3Splice" (out_mp3splice.dll), available for download from Winamp. Occasionally a click is heard (less than 1%, I'd say) and most of these can be cured with a tool like MP3Trim by removing a single frame from the end of one track or the beginning of the next. A small price to pay for having the convenience of access to any track without having to search through a large file.
I haven't had much luck with other programs, though I was able to get good results with MediaJukebox by playing with the crossfading parameters.
why do you use special plugins? you can turn on gapless mode in out_ds, too.
i'm editing my comment to remove the entire comment. even though what i said was true at the time i said it. eventually things changed and i get warned by a mod who didn't bother to check the date on my post, or corroborate if it was true or false at the time.
...le sigh
isn't the rio karma gapless?
isn't the rio karma gapless?
The Karma is only gapless with FLAC and Vorbis. It's mp3 playback is close to gapless, but not true gapless. The Karma's mp3 playback drops the small amount of silence between adjacent tracks. It does this so well that it appears to be gapless most of the time, but in fact, it is still not truly gapless. There are rumors that the Karma engineers are aiming(through future firmware updates)to add gapless mp3 playback with LAME encoded mp3s.
out_ds does NOT do real gapless playback, it's a crossfader and will always be a crossfader untill someone updates Peter's code.
Pyramid mp3-splice or Gapless Output Plugin 0.7.2 (here (http://www.winamp.com/plugins/details.php?id=107818)) or the two other ones on winamp.com that I havnt tried are what you need to play ANY file format truely gapless in winamp, period.
I know I've posted about this at least 5-6 times (although over a year ago so not sure if it's in the search archives anymore or what)
You are repeatedly posting false info then. And probably using wrong settings in out_ds.
isn't the rio karma gapless?
The Karma is only gapless with FLAC and Vorbis. It's mp3 playback is close to gapless, but not true gapless. The Karma's mp3 playback drops the small amount of silence between adjacent tracks. It does this so well that it appears to be gapless most of the time, but in fact, it is still not truly gapless. There are rumors that the Karma engineers are aiming(through future firmware updates)to add gapless mp3 playback with LAME encoded mp3s.
As a (new) Karma owner, I can confirm this. It's closer to gapless than any other hardware player I've heard, but it's not truely gapless. I would, if not on campus, link to the audio sample I think I used from a forum here (thought it may have been a karma forum), that on the Karma, demonstrates the "closeness but not trueness". Between the tracks Parabol and Parabola on Tool's Lateralus, you can hear a small artifact. It's equivalent to a very small microphonic artifact picked up through the cans cable. Thus, it's not true gapless, but, very, very close, and for me, close enough.
Hope that didn't violate the TOS...I'm still new here.
I would, if not on campus, link to the audio sample I think I used from a forum here (thought it may have been a karma forum), that on the Karma, demonstrates the "closeness but not trueness". Between the tracks Parabol and Parabola on Tool's Lateralus, you can hear a small artifact. It's equivalent to a very small microphonic artifact picked up through the cans cable. Thus, it's not true gapless, but, very, very close, and for me, close enough.
http://www.hydrogenaudio.org/forums/index....howtopic=18757& (http://www.hydrogenaudio.org/forums/index.php?showtopic=18757&)
Hope that helps
Hi. I'm a newbie and joined because of this post.
This is only slightly off topic, but can someone tell me or point me to a thread how to convert a Lame >=3.90 mp3 to wave without having to manually trim off the first 1105, 1152, or 2257 samples and then trim the end (if there still is enough data left) so that a song matches the appropriate time down to the exact frame of the original wave from which the mp3 was created?
mpg123 and mp3-splice seem to work quite well with winamp 2.91.
crudsoft's version clicked at the beginning of playback.
have not tried others, could not find out_ds. a link to a download for it would be nice
Holy shit people.
Who cares if its REAL Gapless or Fake Gapless
IF the fake gapless doesnt gap at all, then who gives a flying fuck or not if its "true".
This is only slightly off topic, but can someone tell me or point me to a thread how to convert a Lame >=3.90 mp3 to wave without having to manually trim off the first 1105, 1152, or 2257 samples and then trim the end (if there still is enough data left) so that a song matches the appropriate time down to the exact frame of the original wave from which the mp3 was created?
I haven't actually verified it myself, but I suppose foobar2000's diskwriter will do this properly.
I haven't actually verified it myself, but I suppose foobar2000's diskwriter will do this properly.
I tried the wave writer in Winamp 2.91 with poor results.
Looks like I'll be having to check out foobar2000, though I'm hoping for some kind of command line param for lame.exe -decode.
I felt dumb when I discovered that out_ds.dll is available in the winamp installation.
Thanks for the reply PoisonDan!
I think there's a general confusion about gapless MP3s and gapless playback. As zZzZzZz said, there are really 2 issues with playing back MP3s gaplessly.
For one, MPEG Layer III uses fixed frame sizes, with each frame containing a 32-bit header and 1152 samples. So what happens when the song you are ripping from the CD is not evenly divisible by 1152 samples? In this very common scenario, the last frame will have to fill the remaining space with dummy samples (silence). The worst case scenario would be having the very last sample of the song as the first sample in the last frame. There would need to be 1151 dummy samples placed in this last frame. That’s roughly 26 milliseconds (or about 1/40 of a second) of silence. A work around for this problem would be to rip the entire album as one MP3 file, as was mentioned by DonP, and then use an MP3 cutting program to cut each song on a frame boundary. Of course, because you'd be cutting on frame boundaries the resulting songs would not be exactly as they would be if you were to rip and encode each song individually. But again, worst case you'd only be off by as much as 26 milliseconds from the original. Hardly noticable, and well worth it, when your goal is to create MP3s that fill each frame entirely (of course the last song of the album would still have dummy samples inserted in its last frame, but this is immaterial since the last song doesn't transition into another song).
If you work around the fixed frame size limitation of MP3s by using the above method, you've created MP3s completely capable of gapless playback, despite what AtaqueEG said. You don't need any funny Lame header info to tell you how to play the songs back gaplessly. All you need is a player that doesn't insert any gaps through its decoding process, which is the second (and rather trivial) requirement for gapless playback of MP3s.
A software MP3 player reads the songs from disk (the likely source) and buffers a portion (if not all) of the song in memory to be sent to the decoder logic. In the case of a very large MP3 file, that may not fit entirely in memory, the player may need to continually fetch portions (or frames) of the song and feed them into the buffer in memory to be used by the decoder. In the case of two songs, that were cut on frame boundaries to avoid having any gaps inserted, a similar approach can be made to continually feed the buffer used by the decoder. The only complication is the ID3 header which, in the case of ID3v1 (128 bytes), is located at the end of the track. ID3v2 header info may be located at the beginning or the end, but it is often located at the beginning. The player simply has to be "intelligent" enough (again, this is rather trivial) to read the ID3 tag information for the next track, and avoid placing it in the buffer that is used by the decoder. If it does, it can merely abut two songs in this buffer and the two songs would be decoded gaplessly. If an MP3 player is not capable of this, it is poorly coded.
If you don't believe me, I ask you to perform a quick experiment. Take an MP3 file and cut it on a frame boundary into two MP3s (using say MP3DirectCut). The two MP3s should each contain their own ID3 header. If the two MP3s do not play gaplessly on your software MP3 player, then you are using a poorly coded MP3 player (and you should likely write the author of the program to let them know that, so that he could improve it). Now, concatenate the two MP3 files together and hexedit the file to remove the ID3 header information that will naturally lie between the two songs (use ID3v1 to keep it simple, since the header will be 128 bytes). You should now have one MP3 file that was joined from the two cut MP3s. Play the single file on the same MP3 player. Do you now hear a gap where you did before? You certainly shouldn't, since it is only one song afterall. This merely proves that multiple MP3s that were cut on frame boundaries should have no problem playing gaplessly, as long as the MP3 player doesn't choke on the ID3 header information and correctly abuts the two songs.
Thanks. Sorry for the long post.
With all of this being said, I'm wondering if any of the rippers (EAC and others) have the smarts to rip a CD as one complete .WAV file, encode it as one MP3 file, and cut the flie into the tracks of the CD on frame boundaries (but as close to the original position of the tracks as possible). Does anyone know if this is possible? Or, doesn't LAME have a --nogap option that takes a series of .WAVs (say from the same album) and encodes them gaplessly? I'm assuming it's essentially doing as I described, and evaluates the series of .WAVs as one song ensuring that each track ends on a frame boundary. This option could be used with EAC if it could rip the entire album before encoding, but it seems as if it only allows you to rip and encode each track one at a time.
If you work around the fixed frame size limitation of MP3s by using the above method, you've created MP3s completely capable of gapless playback, despite what AtaqueEG said. You don't need any funny Lame header info to tell you how to play the songs back gaplessly.
You method won't work as the first frame can not be properly decoded because of the mdct.
The only way is to store encoder delay and padding values. This is not "funny", it is just usefull.
This is slightly off topic:
Is AAC gapless?
This is slightly off topic:
Is AAC gapless?
Depends on the player and encoder support (just like MP3).
Nero AAC + foobar decoder for example is gapless
I keep seeing questions about ripping an entire cd to a single mp3. I do it all the time and here is my $0.02 based on successful experience:
Exact Audio Copy will allow you to rip an entire cd to a single wave file. Further, it creates a cuesheet that (among other things) indicates where each track begins down to the exact frame. You can then convert this wave file to single mp3 of the entire cd.
MusiCutter is a program that can then use the cuesheet to cut the single mp3 into individual tracks. Because mp3 frames are 1152 samples long and cd frames are only 588, the cut points won't be perfect, but MusiCutter manages to get them to the nearest mp3 frame which will should be no more than 587 samples off from the original. This program works equally well with VBR or CBR.
You can then use AlbumWrap to combine the separate tracks back into a single mp3 of the album again. Providing that you don't create any id3 tags for the separate tracks before wrapping, the resulting wrapped mp3 will be identical to the single mp3 before wrapping. This is verifiable by converting each to wave and performing a file compare or subtractive comparison with a wave editor.
All this said, there are a couple caveats. First, I have only used Lame 3.92 and higher for this. Second, before someone flames me, playback of the individual tracks separately will not be gapless unless you are using a player that is configured to play that way (foobar2000, winamp with plugins). Playback of the wrapped or single mp3 WILL be gapless on ANY player, however. Please don't waste your time talking about the extra samples before or after the entire album, LOL!
Skipping tracks when playing an entire album can be a pain. With Winamp v2 (old habits die hard), I like to use a plugin called mp3cue which uses the cuesheet to allow you to skip tracks during playback. If you don't want to deal with a separate .cue file, this plugin will also allow you to embed the cuesheet into the id3v2 tag. This plugin is very buggy and often crashes if id3v2 tags have embedded images. Finally, mp3cue doesn't seek well with VBR or for some reason it doesn't seek well Lame 3.95 VBR or CBR.
I'm still trying to find a stand-alone codec that can convert Lame mp3 tracks to wave without additional samples at the begining or end. If foobar2000 and Winamp with plugins can play mp3s back gaplessly, why can't something convert them to wave gaplessly? HELP!!!
If foobar2000 and Winamp with plugins can play mp3s back gaplessly, why can't something convert them to wave gaplessly? HELP!!!
foobar decodes to WAV gaplessy (without any plugins)
I'm still trying to find a stand-alone codec that can convert Lame mp3 tracks to wave without additional samples at the begining or end. If foobar2000 and Winamp with plugins can play mp3s back gaplessly, why can't something convert them to wave gaplessly? HELP!!!
If the mp3s you want to decode to .wav were created by splitting one big mp3, gapless decoding is messed up because mp3 frames overlap. Additionally you will get glitches at transitions of tracks sometimes because of broken bit reservoir. If you want gapless decoding from single mp3 files, rip to seperate tracks and encode them to mp3. Decoding with foobar2000 to .wav will work without glitches or gaps.
Tigre makes a good point:
you will get glitches at transitions of tracks sometimes because of broken bit reservoir.
This may happen if you play tracks originally split from a single file, though it shouldn't happen if you play them from within a wrap you have created from the split tracks.
Regarding my question regarding converting mp3 to wave and not having to trim additional silence, please assume that I will be dealing with mp3 files created with Lame later than 3.89 from individual tracks off a cd.
My post earlier had two
separate parts--one on splitting, wrapping and resulting playback, the other about converting to wave without having to edit extra samples.
I will try foobar2000 to do this, but would prefer a method dedicated exclusively to this task. Too bad for me that I'm not able to create my own...
If you rip and encode each track individually, you will almost certainly have dummy samples in the last frame of each track, which will undeniably be played as gaps. That's why LAME header information would certainly be needed in this case.
But, if you were to rip and encode the entire album as one track, and them split this on frame boundaries into the individual songs, you would have no dummy samples in the last frame of each track (besides the very last track of the album). All that would be needed to play these split songs gaplessly, would be to overcome the byte reservoir and frame dependancy. It would seem that this limitation could be overcome by an intelligently programmed decoder. The fact that the wrap program that greynol mentions can patch back the split songs into the same exact single MP3 suggests that this is indeed possible on the decoder's end.
Can anyone point me to an informative document on the byte reservoir and any frame dependencies that exist with MP3? I haven't had any luck finding any with a search engine. thanks.
J. River Media Center appears to support gapless playback.
For me, the test is to listen to 'The Word' from 'This Is The Moody Blues' transition into 'Eyes Of A Child' from 'This Is The Moody Blues'
Sounds right to me using MC 10.112
I'm still trying to find a stand-alone codec that can convert Lame mp3 tracks to wave without additional samples at the begining or end. If foobar2000 and Winamp with plugins can play mp3s back gaplessly, why can't something convert them to wave gaplessly? HELP!!!
I'm assuming that your question is related to split mp3 files from an original album length mp3 file. These resulting files will not be converted by foobar or any other decoder for that matter gaplessly. Foobar will convert only single LAME 3.90+ mp3s (gaplessly) that have been extracted track by track, not split from one large track. LAME header information is not added to the split mp3 files so therefore cannot be decoded gaplessly. I don't know of any program that can recover the LAME header to retain gapless playback after files have been split. I'll ask a similar question:
Could a program possibly exist that would re-apply the LAME header information after or during the splitting process, and is that even possible to do given the limitations of mp3?
I found a little bit of information on the "byte reservoir" of MP3, but not a whole lot. Seems like just because a particular frame may be borrowing bandwidth from previous frames doesn't mean that the decoder should choke when it reaches a new track. As long as it keeps an adequate sized buffer for the frames it decodes, it should be able to refer to frames from a previous track without problem. So it would seem that a well written MP3 decoder should be able to playback MP3s gaplessly without any special header information as long as special care is taken to make sure that no dummy samples exist in the last frame of each track (i.e. by cutting the album sized MP3 on frame boundaries for each track).
As an assist to the decoder, the encoder could even avoid using the "byte reservoir" for the first several frames of a track (to avoid it referring to frames of a previous ftrack), even if it means using a high bitrate for these frames.
So it would seem that an alternative to the current --nogap option in LAME would be to take a series of .WAV files from an album and essentially treat it as one big music file. LAME would ensure that each track fills up all of its frames (which would result in the start, and therefore end, of songs being shifted by at most 1151 samples or 1/40 of a second). LAME would also avoid having the frames of each track referring to frames from the previous track (byte reservoiring could be used as long as its kept within each track; no cross referencing). With this, all you would need is a decoder that doesn't artificially add a pause as it transitions from one track to another (which is absurd if it does, as it can simply load the next track immediately behind the current track in the buffer it uses to decode from).
This of course assumes that byte reservoiring is the only frame inter-dependency that exists in the MP3 specification. Is this true?
This of course assumes that byte reservoiring is the only frame inter-dependency that exists in the MP3 specification. Is this true?
No, it is not. There is also the MDCT transform itself.
ChangFest , you are right about the Lame header, BUT,
As I stated earlier,
please assume that I will be dealing with mp3 files CREATED with Lame later than 3.89 from individual tracks off a cd
I wouldn't ever bother trying to create waves from mp3s that came from a split mp3 album, rather I would use a program like CueMaster to generate a cuesheet from a freedb.org submission. I would then use that cuesheet to cut up a wave file created by the album prior to splitting.
bennybenz :
You can disable the bit reservoir in Lame by using the --nores switch.
Myself, I am not concerned with the --nogap switch, which is more or less obsolete. Lame >3.89 includes information in the header to tell an intelligent decoder (like mpg123) how many samples to skip at the beginning and the end of a file for gapless playback.
Finally, using AlbumWrap to piece back an album from tracks originally split from the album using MusiCutter WILL preserve the bit reservoir, provided that there are no id3 tags in the split tracks. I know this by using a program called tidymp3.exe that removes all tags including the ALBW header from the wrapped ablum and the original mp3 album, and then using fc.exe (File Compare). The two files are bit-for-bit IDENTICAL.
Anyhow, foobar2000 does indeed create waves with the correct length from a Lame >3.89 file created by an individual track (I didn't bother to test a split mp3 track). So thanks to everyone who told me this--But I'd still like to see a seperate decoder. Maybe I'll hit up Spoon over at www.dbpoweramp.com!!!
This of course assumes that byte reservoiring is the only frame inter-dependency that exists in the MP3 specification. Is this true?
No, it is not. There is also the MDCT transform itself.
Gabriel, do you mind expanding on this a little more? How is there a frame inter-dependency (meaning one frame being dependent on an adjacent frame) between the DCT data itself, outside of byte-reservoiring?
Also, if you created MP3s from an album that completely filled all of their frames with actual song data, then how could any decoder not be able to play these MP3s gaplessly if it were to remove the ID3 data and abut each of the MP3s' song data as one continuous playback stream? I see no reason why not.
Also, what information does LAME place in the header for gapless playback? If it's simply info related to how many dummy samples exist in the last frame of each song (so that the decoder can avoid playing these artificial gaps), then that proves to me that a decoder could similarly play back songs gaplessly that simply avoid having any dummy samples in their last frames.
RealPlayer 10 Plus has a crossfade option that you can set to "0". Also, the iRiver iHP-120 is supposed to support gapless playback in a forthcoming firmware update.
OK, without realizing it, I had crossfading turned ON with WMP9 (with 0 seconds as the gap). So I turned it OFF, but still get gapless playback (no interruption in the stream) but a tiny "click" between tracks (i.e., I'd know there was a track break there because of the click).
Don't know why the other guy would be getting a 2-second gap!
First time it seems that WMP buffers things as I got a big lag first time but right now it's just a small skip / click.
I checked and it's 0.05 second skip.
(http://mat128stuff.free.fr/wmpskip.gif)
@ bennybenzI'm obviously not Gabriel but I couldn't resist to comment on this.
How is there a frame inter-dependency (meaning one frame being dependent on an adjacent frame) between the DCT data itself, outside of byte-reservoiring?
In the synthesis step of the decoder the audio samples from the current frame are combined with the previously decoded samples (overlapping windows). This dependency of consecutive frames is in the very nature of the transformation used in encoder and decoder. It reduces (eliminates?) blocking artifacts that would be prominent if the transform windows didn't overlap.
Also, if you created MP3s from an album that completely filled all of their frames with actual song data, then how could any decoder not be able to play these MP3s gaplessly if it were to remove the ID3 data and abut each of the MP3s' song data as one continuous playback stream? I see no reason why not.
The reason is the transform overlap (as mentioned above) at the beginning of each file. If the decoder has no special "gapless" mode then it starts decoding of each new file with an empty (silent) transform buffer, which results in a small gap (silence) in the output.
Also, what information does LAME place in the header for gapless playback?
I don't know and leave that one for Gabriel or somebody else.
By the way:
The bit-reservoir works on a different level. It is part of the bit stream (encoded data). Its purpose is to provide some kind of "variable bitrate" even in CBR encoded streams. The bit-reservoir can be seen as a "dynamic buffer" inside the bitstream.
(F are frame headers, the numbers are the contents of the respective frames)
Ok, this is an illustration of a bitstream that does *NOT* use the bit-reservoir.
F 1111111111 F 2222222222 F 3333333333 F 4444444444 F...
You can see, frame headers and contents are nicely ordered.
Now, an illustration of a bitstream that *DOES* use the bit-reservoir:
F 1111122222 F 2333333333 F 3333333333 F 4444444555 F...
Here the frames 1 and 2 use less bits than they could, so they build up the reservoir. Frame 3 uses much more bits than its own frame could contain and uses additional bits from the reservoir. After frame 3 the reservoir capacity is reduced to 0 (zero), so the contents of frame 4 have to start right after the fourth frame header.
The different sizes of the frame contents result from the audio signal and how "difficult" it is to encode it.
Bit reservoir makes MP3 file splitting quite a challenging task because the beginning of the second piece must be modified by the splitter program to save the bit-reservoir contents that are actually located at the end of the first piece. Just try to image that you want to split the example from the second illustration between frame 2 and 3...
Hope this little (?) explanations makes sense to anybody.
This is pretty old topic... Any progression in this area? I'm going to buy an MP3 player which should support gapless MP3 playback (and CUEs too, but maybe I'm just daydreaming )
Besides the Rio Karma and some Rockbox compatible DAPs (such as the iRiver H120 or H320) i don't know any hardware mp3 player that supports real gapless playback.
As for cue playback... i don't know any. But keep an eye on the Rockbox community, they may implement it one day.
Thanks to Rockbox, quite a few Ipods now, too (like the Nano).