Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[lalittle]

I read that ever since the LAME mp3 encoder version 3.90.3, the amount of silence added to the beginning or end of the track during encoding is stored within the file.  This in turn allows the playback to maintain the exact, original length of the song, which eliminates the gaps normally associated with mp3 songs.  If this is the case, why are there still gaps in mp3 playback?  I know that MC uses the 3.93.x LAME encoder -- does it not take advantage of the extra information, or does this simply not work as well as I've been led to believe?

Thanks,

Larry

[lalittle]

Here is a quote from http://en.wikipedia.org/wiki/Gapless_playback.  This discusses the fact that mp3's can now achieve gapless playback as long as the playback software supports reading the metadata in the file (which the newer LAME encoder supposedly utilizes.)

Optimal solution
Where gaps are caused due to the compression process, it is technically possible to store metadata with the audio to explicitly declare the amount of delay/padding introduced in the encoding process. This information can be used to ensure that playtime will remain constant after decoding with no added silence. The audio playback software must be able to recognize the metadata, and trim the decoded audio as necessary. For uncompressed audio formats this sort of information is generally redundant; the start and end of the audio is well-defined.

To address the effects of poor design, player software needs to achieve two main effects: ensuring the audio hardware itself is not stopped and started between tracks such that a click is added; and looking ahead slightly to process the next track while the current one is running, such that the data for the next track is immediately ready as the current one draws to a close.

If these areas are addressed, such that the software properly decodes the audio data and metadata, the next track is buffered and ready to play and the output stream remains open between tracks, optimal gapless audio is achieved. A collection of consecutive tracks will then play in the same way they were mastered, allowing the listener to hear their album as the author intended.

Does MC simply not yet support this metadata?  The article above lists some programs that do support it, but Media Center is not listed.  Does anyone know if this is going to be incorporated into MC?  I listen to a lot of albums that require gapless playback (progressive rock) so this is important to me.  I still find myself turning to the original CDs because of this, but it would be really nice to be able to use my online library for listenning to this type of album.

Thanks for any information on this,

Larry

[hit_ny]

The best practice method for gapless playback with mp3s (for some years now) is to rip with a cue file. Of course you then need a player that can understand cue. MC does this currently. I'm still holding off for a portabe player that can do this.

Thing with the gapless info is all cool and everything but you need to have ripped your collection with it for it to work. Does MC support it yet, no idea.

[Alex B]

Does MC simply not yet support this metadata?  The article above lists some programs that do support it, but Media Center is not listed.  Does anyone know if this is going to be incorporated into MC?  I listen to a lot of albums that require gapless playback (progressive rock) so this is important to me.  I still find myself turning to the original CDs because of this, but it would be really nice to be able to use my online library for listenning to this type of album.

The decoder must be designed to use that LAME tag info. Also, it works only with files that are encoded with a recent LAME version. MC decodes in the standard way and does not support this (yet?). Basically the system is a hack that fixes this mp3 format design flaw.

Currently the truly gapless lossy formats in MC are Ogg Vorbis and Musepack. Naturally the lossless formats are gapless too.

[Alex B]

I read that ever since the LAME mp3 encoder version 3.90.3, the amount of silence added to the beginning or end of the track during encoding is stored within the file.  This in turn allows the playback to maintain the exact, original length of the song, which eliminates the gaps normally associated with mp3 songs.  If this is the case, why are there still gaps in mp3 playback?  I know that MC uses the 3.93.x LAME encoder -- does it not take advantage of the extra information, or does this simply not work as well as I've been led to believe?

I just noticed this. By default MC10 used the v 3.93.1 and MC11 used the v. 3.96.1. MC 11.1 uses the v. 3.97b2.

LAME 3.90.3 was actually newer than 3.93. The official LAME builds were 3.91, 3.92, 3.93 etc, but Hydrogen Audio founder Dibrom made the special 3.90.2 and 3.90.3 builds and HA recommended 3.90.3 until last fall. Currently also HA recommends LAME 3.97b2.

[Link]

Also, MC already has the "Trim Silence" option which works great for me at doing this exact thing....  So I'm not too worried about them adding this.

[hit_ny]

Currently, also HA recommends LAME 3.97b2.

I hear its better than 3.90.3 at lower bitrate encodes ie 128kbs etc,

but does it do better at higher encoding rates, aps etc. too ?

[Alex B]

Also, MC already has the "Trim Silence" option which works great for me at doing this exact thing.... So I'm not too worried about them adding this.

It removes all intended silence too. Many albums have both types of track changes.

[Alex B]

I hear its better than 3.90.3 at lower bitrate encodes ie 128kbs etc,

but does it do better at higher encoding rates, aps etc. too ?

It is especially better when medium bitrate VBR encoding is used together with the --vbr-new option. Actually, no one has properly tested the v.3.97b2 CBR and ABR modes at about 128 kbps since the current VBR mode is supposed to be better.

At high bitrates it is at least not significantly worse. Probably it is better with many music tracks, but the opposite is also possible.

Comparisons at ~200 kbps VBR are very difficult. With standard music and in casual listening it is almost impossible to hear any difference between the encoders or distinguish the encodings from the original.

ABX testing with HQ headphones and short problem samples is usually needed for making any difference between the modern VBR encoders at high bitrates.

[lalittle]

The decoder must be designed to use that LAME tag info. Also, it works only with files that are encoded with a recent LAME version. MC decodes in the standard way and does not support this (yet?). Basically the system is a hack that fixes this mp3 format design flaw.

But as long as it works, this is all that really matters, and this fix offers the advantage of the mp3 format having such widespread support.  The only question is how well it works -- does anyone know if it's "exact" enough to eliminate the gap without disrupting the waveform at ALL?

Currently the truly gapless lossy formats in MC are Ogg Vorbis and Musepack. Naturally the lossless formats are gapless too.

Unfortunately, I need mp3's since I need them to work on a portable player as well (iPod at the moment.)  That said, wav files are also lossless and are also supposed to be gapless, but I'm currently getting a pop in between many wav file tracks.

Thanks for all the feedback,

Larry

[lalittle]

Also, MC already has the "Trim Silence" option which works great for me at doing this exact thing....  So I'm not too worried about them adding this.

As Alex mentioned, this also removes silence that's SUPPOSED to be there, which prevents this from being a solution for the type of music I listen to.

Larry

[geekbeats2]

ok.. so  media center DOES NOT support gapless mp3 playback??
why wouldnt it? even the new version of winamp does, as do many other media players. Why would this not be implemented in media center??

[lalittle]

ok.. so  media center DOES NOT support gapless mp3 playback??
why wouldnt it? even the new version of winamp does, as do many other media players. Why would this not be implemented in media center??

Given MC's wealth of advanced features, I would think that this would be supported soon, but I was hoping that JRiver would confirm this.  It makes sense that MC would support this capability with mp3 files given that it uses the LAME encoder by default, and the LAME encoder that it currently uses apparently DOES embed the metadata necessary for this.  It seems like it's just a matter of having MC USE this metadata, but I have absolutely NO idea how complex this is.  You're correct that newer versions of some of the other playback software does support this, but as far as I know this is a fairly new addition, so my guess is that MC hasn't had time to implement this yet.

If anybody has more information on this subject please let us know.

Larry

[lalittle]

3. NEW: MP3 playback supports LAME-tags for high-quality gapless support.

Wow -- that's great news!  Thanks for deciding to support this, and for somehow implementing it in record time!

Larry

[lalittle]

3. NEW: MP3 playback supports LAME-tags for high-quality gapless support.

I finally got a chance to try this, and in a word, this is AWESOME!  I haven't tested it very much yet, but so far it seems to work wonderfully.  This is the first time I've heard "true" gapless mp3 playback that really seems to work.

I'll need to re-rip some of my albums with the newer encoder to really test this -- I'll post back after I get a chance to do this.  Fantastic work guys -- THANK YOU for implementing this!

Larry

[Mastiff]

OK, I'll bite (sucker as I am...): How new does the LAME has to be to work with this? I have a few live albums I may re-rip...

[JaredH]

I finally got a chance to try this, and in a word, this is AWESOME!  I haven't tested it very much yet, but so far it seems to work wonderfully.  This is the first time I've heard "true" gapless mp3 playback that really seems to work.

I'll need to re-rip some of my albums with the newer encoder to really test this -- I'll post back after I get a chance to do this.  Fantastic work guys -- THANK YOU for implementing this!

Larry

So if we are playing files that were ripped using the old LAME encoder, we won't get gapless? Am I understanding that correctly?

[TimB]

11.1.138 (3/3/06)

1. Changed: Unplugging or hard-killing MC while it is writing the iPod database will no longer corrupt the iPod database.

Didn't notice this before.

Bless you!

-=Tim=-

[Alex B]

Probably that LAME tag based system would need a completely rewritten input plug-in and still it would help only LAME encoded mp3 files. It is not something that you can quickly include in the next build.

Well, I was wrong...    

11.1.137 (3/3/06)

3. NEW: MP3 playback supports LAME-tags for high-quality gapless support.

Some first reactions:

I finally got a chance to try this, and in a word, this is AWESOME!  I haven't tested it very much yet, but so far it seems to work wonderfully.  This is the first time I've heard "true" gapless mp3 playback that really seems to work.

I'll need to re-rip some of my albums with the newer encoder to really test this -- I'll post back after I get a chance to do this.  Fantastic work guys -- THANK YOU for implementing this!

OK, I'll bite (sucker as I am...): How new does the LAME has to be to work with this? I have a few live albums I may re-rip...

So if we are playing files that were ripped using the old LAME encoder, we won't get gapless? Am I understanding that correctly?

I am currently trying to find out when the LAME encoders started to add the needed info and how old files can be checked without listening through them. (I searched at Hydrogen Audio and I have now a huge list of HA threads in front of me...)

It seems that the special HA version 3.90.3 added the information. But I am not sure when the more "official" builds started to add this LAME tag info (explained here: http://gabriel.mp3-tech.org/mp3infotag.html). Certainly the v.3.96.1 (MC10 & MC11.0) and v.3.97b2 (MC11.1) are fine. I hope that also the v.3.93 (MC9) encoded files contain the needed info. I have a lot of files encoded with it.

Perhaps some tools can tell the difference. The search continues...

[hit_ny]

Acid test, use disk writer to output playback of seperate tracks to a wav file and compare with the cd ripped as one big file. If this LAME solution is truely gapless there should not be any difference. Much more accurate than listening.

I wonder whether any info about the new gapless encoder is put into the lame header. I use a tool called lametag to get this info but have not seen any info regarding gapless in the header.

[lalittle]

So if we are playing files that were ripped using the old LAME encoder, we won't get gapless? Am I understanding that correctly?

As far as I know, you are understanding it correctly.  The only things that are still unclear are:

1)  At what point did the "official" LAME encoder start using this metadata (and when did MC start using this as their default encoder)?

2)  How can we tell which encoder was used to encode any given song?

Acid test, use disk writer to output playback of seperate tracks to a wav file and compare with the cd ripped as one big file. If this LAME solution is truely gapless there should not be any difference.

I'm not sure whether this would work or not.  When you rip as seperate tracks, does the last sample of one song necessarily match up with the first sample of the next song?  In other words, is it possible that you could have a slight mismatch in the waveform between two mp3's (due to the compression taking place) that could still potentially cause a slight pop accross the transition?

Or, does ripping two songs as a single big song create the EXACT same waveform accross the transition as you get by ripping the two songs seperately, then letting the decoder join them using the metadata in the file to remove the silence?  I'm honestly not clear whether or not the "LAME metadata" method always results in a "perfect" match accross transitions.  In my subsequent tests, I noticed that I could still hear a very small click during the transitions between some quieter songs.  I don't know if this is simply a limitation of the format, or if I need to re-rip the songs with a newer LAME encoder.  I won't be able to test this until next week.

Thanks for any other information on this, or for sharing any test results here.

Larry

[Alex B]

Starting from the original LAME 3.90 release the Info Tag has been included by default. The LameTag tool can display if the files have the needed information.

As a test I encoded a file with the first LAME 3.90 release build (from December 21, 2001). I used a typical CBR command line switch: "-b 192 -h". Here is the LameTag info:

>lametag.exe "04 - Lemon.mp3"

LameTag - Reads the LAME tag from an mp3 file
Copyright (c) 2005 phwip
Release 0.4.1, compiled 2005-09-09

E:\Test\LameTag\U2 - Zooropa\04 - Lemon.mp3
Tag revision:       0
Encoder string:     LAME
Version string:     3.90
Quality:            58 (V4 and q2)
Encoding method:    cbr
Lowpass:            18.700Hz
RG track peak:      <not stored>
RG track gain:      <not stored>
RG album gain:      <not stored>
nspsytune:          no
nssafejoint:        no
nogap continued:    no
nogap continuation: no
ATH type:           2
Bitrate:            192
Encoder delay:      576 samples
Padded at end:      1.452 samples
Noise shaping:      1
Stereo mode:        stereo
Unwise settings:    no
Source sample freq: 44.1kHz
MP3Gain change:     <none>
Preset:             <not stored> - unable to guess
Surround info:      none
Music length:       10.039.169 bytes
Music CRC:          6A63
Actual Music CRC:   6A63

These two lines are needed for gapless playback:
Encoder delay:      576 samples
Padded at end:      1.452 samples.

It would be nice if MC could show if the file contains this info in Action Window > File Properties > File Type Info.

[Alex B]

These tools can be used for checking what encoder was used:

EncSpot Basic: http://www.afterdawn.com/software/audio_software/mp3_tools/encspot.cfm
Mr QuestionMan: http://www.burrrn.net/?page_id=5

[datdude]

Starting from the original LAME 3.90 release the Info Tag has been included by default. The LameTag tool can display if the files have the needed information.

As a test I encoded a file with the first LAME 3.90 release build (from December 21, 2001). I used a typical CBR command line switch: "-b 192 -h". Here is the LameTag info:
These two lines are needed for gapless playback:
Encoder delay:      576 samples
Padded at end:      1.452 samples.

It would be nice if MC could show if the file contains this info in Action Window > File Properties > File Type Info.

I'm confused.

Is this saying that potentially any lame mp3 version can now playback gapless?

Also I'm wondering if we should sitll leave the 'do not play silence' option on?  I never liked that on since it got rid of stuff it shouldn't, but if maybe it only does it for those mp3's that don't have the gapless info, then that would be ok.

[Alex B]

I'm confused.

Is this saying that potentially any lame mp3 version can now playback gapless?

Yes, starting from LAME 3.90. (Info Tag writing can be disabled with a LAME switch, but it is enabled by default. Also, some taggers may have corrupted or removed the tag.)

Also I'm wondering if we should still leave the 'do not play silence' option on? I never liked that on since it got rid of stuff it shouldn't, but if maybe it only does it for those mp3's that don't have the gapless info, then that would be ok.

If you like to play MP3 files gaplessly use only LAME 3.9x encoded files that have correct LAME Info tags and enable only the "Gapless" mode.

If I have understood this correctly all track transition effects are applied after the gapless decoding. "Do not play silence" removes any kind of silence at the track boundaries just like before.

[datdude]

Yes, starting from LAME 3.90. (Info Tag writing can be disabled with a LAME switch, but it is enabled by default. Also, some taggers may have corrupted or removed the tag.)

So far all albums on mine seem to be perfectly gapless.

It would be really interesting if MC could creat a smartlist to tell you what files have this and do not have this.

I am wondering if these tags could be edited and the ones that for whatever reason don't have the info, could changed so that if someone else had an album with the info, could share it to us that don't seem to have it!

[hit_ny]

These two lines are needed for gapless playback:
Encoder delay:      576 samples
Padded at end:      1.452 samples.

What about

nogap continued:    no
nogap continuation: no

don't these have to be yes ?

[Pink Waters]

I checked all my library..
They are lame 3.93 !
So as far as I read here,.. the support the new thing..!

But I tested many gapless tracks with the latest build of MC and i have that click/pops between tracks!!

[Alex B]

Check the files with LameTag. If they have correct Info Tags and still don't play gaplessly you could mail samples to Matt.

[Alex B]

What about

nogap continued:    no
nogap continuation: no

don't these have to be yes ?

No   

(Encode a file with LAME 3.97b2 and check it with LameTag.)

[Matt]

You may still get a slight tick even with the new support.  This is due to the MDCT buildup times of the encoder and decoder.  Foobar exhibits the same tick between tracks.

Our decoding start sample perfectly matches the decoder built into LAME.  The stop samples are also perfectly preserved.  I believe MC does as good of a job as possible now.  It will be "perfect" for most people.

If it still isn't seamless enough you you, your best bet would be to rip as one large file or to use lossless.

We'll output the gap information in Action Window > File Type Info section in a coming build so you can check it.

[Pink Waters]

Check the files with LameTag. If they have correct Info Tags and still don't play gaplessly you could mail samples to Matt.

sorry, what is lametags ? software ?

[Alex B]

sorry, what is lametags ? software ?

LameTag is a program. I explained it and provided a link a few posts ago:

http://yabb.jriver.com/interact/index.php?topic=32377.msg222212#msg222212

[Pink Waters]

Alex B, Just checked all the library,...
They are O.K and have the info though!

[Alex B]

You may still get a slight tick even with the new support.  This is due to the MDCT buildup times of the encoder and decoder.  Foobar exhibits the same tick between tracks.

Our decoding start sample perfectly matches the decoder built into LAME.  The stop samples are also perfectly preserved.  I believe MC does as good of a job as possible now.  It will be "perfect" for most people.

If it still isn't seamless enough you you, your best bet would be to rip as one large file or to use lossless.

We'll output the gap information in Action Window > File Type Info section in a coming build so you can check it.

MDCT = modified discrete cosine transform ?
http://en.wikipedia.org/wiki/Modified_discrete_cosine_transform  (not that I understand it)

Here is HA's "Gapless" Wiki page:
http://wiki.hydrogenaudio.org/index.php?title=Gapless

The page has a link to a package of 17 short samples that can be used for testing gapless playback:
http://guruboolez.free.fr/samples/gapless/gapless_WAVPACK_free_of_right.zip

I converted the wavpack files to MP3 and noticed that MC has problems with some of the track changes. Foobar is better for some reason. The MP3 files are in this package: GurusGaplessSamples.zip (1.2 MB).

[JimH]

I converted the wavpack files to MP3 and noticed that MC has problems with some of the track changes. Foobar is better for some reason. The MP3 files are in this package: GurusGaplessSamples.rar (1.2 MB).

WAV Out?  Direct Sound?

[Alex B]

I tried ASIO, Direct Sound and Wave Out. The audible pops were identical.

I don't think the output mode makes any difference on this PC.
(P4 / Intel 865PE chipset / XP SP1 / Terratec DMX 6fire audio)

I can't reproduce the possible Direct Sound issue that makes pops or clicks in the middle of the files or when starting playback of a single file.

[Matt]

Alex, I get some ticks with Foobar and MC using your samples. 

Since different decoders have slightly different delays and buildups, it seems logical to expect slight variations in how the tick sounds.

[Alex B]

Alex, I get some ticks with Foobar and MC using your samples.

Since different decoders have slightly different delays and buildups, it seems logical to expect slight variations in how the tick sounds.

Not quite so. As you may know I don't usually claim things like that without testing thoroughly first.

I made two combained disk writer output files (with MC11.1.139 & foobar2000 0.83).

I played the files with Wavelab and monitored the differences. Here are my notes:
 
   time   MC                      foobar

   5.9 s  MC medium pop
 10.2 s  MC medium Pop
 15.7 s  MC loud pop         FB slight pop
 20.7 s  MC slight pop
 30.4 s  MC medium pop
(36.2 s  pop in the recording)
 40.6 s  MC slight pop
 45.6 s  MC medium pop
 59.9 s  MC medium pop
 75.5 s  MC slight pop
(77.1 s  pop in the recording)
 80.7 s  MC loud pop

foobar made only one very slight pop.

Also the files lengths are slightly different:

MC
85s 596 ms
3774787 samples @ 44100Hz
File size: 15 099 192 bytes

foobar
85s 800 ms
3783780 samples @ 44100Hz
File size: 15 135 164 bytes

I can mail the output files if needed.


P.S. I would like to ask to add MC to the gapless Wiki page (or do it myself), but I can't do that if the test files available on the same page don't play as well as when played with foobar.

[lalittle]

You may still get a slight tick even with the new support.

This has been my experience.  It seems like you're more likely to hear a slight click in quiet transitions -- most likely because louder transitions will tend to mask the pop.  It's still MUCH better than the previous workarounds for this issue.

I'm still curious about Alex's tests finding Foobar to produce fewer pops.  Is this simply due to the "MDCT buildup times of the encoder and decoder" as Matt said -- i.e. will you always find differences in this regard between different programs using this capability?

Alex, can you possibly provide a "zip" version of the mp3's as well as a rar version?  On a related note, is there a free program available to uncompress rar files?

Thanks -- and THANKS again to JRiver from implementing this feature.

Larry

[Alex B]

I replaced it with a zip package.

GurusGaplessSamples.zip (1.2 MB)

Also, here are the diskwriter output files if you like to compare what I hear here with your output. (I compressed them with Ogg Vorbis to save some space)

DiskWriterFilesOgg.zip (2.5 MB)

[Alex B]

I installed and tried Winamp 5.2 too. They have announced a similar support for LAME Info Tag. It failed badly in DirectSound output mode and produced loud and clear clicks and pops, but on the other hand WaveOut and Disk Writer were perfect.

[lalittle]

I installed and tried Winamp 5.2 too. They have announced a similar support to LAME Info Tag. It failed badly in DirectSound output mode and produced loud and clear clicks and pops, but on the other hand WaveOut and Disk Writer were perfect.

When you say "perfect," do you mean NO pops or clicks at ALL?  Is it possible to "literally" have the playback end up as it would have been if the file was ripped as a single file, with a PERFECT recreation of the waveform such that it has absolutely NO click?

Thanks again for all your help with this,

Larry

PS -- Thanks for posting "zip" files files.

[Alex B]

I didn't inspect the waveforms. I would say "audibly perfect". I couldn't hear any gaps.

EDIT

Here is the Winamp 5.2 output file: DiskWriterFileWA52.zip (1.3 MB)

[lalittle]

I just tried Alex's test of the Beethoven mp3 files.  I could hear clicks on all but a couple of the quiet passages.  I didn't really notice any clicks on the louder passages, which (once again) I assume is because any clicks that might be there are masked.  I believe that of the "quieter" transitions, two of them had no noticeable click.

Alex -- What's your theory on why the other programs don't produce any noticeable clicks, and do you think this is something that's "fixable," or is it just a "luck of the draw" situation where some decoding engines are just different than others, which leads to these differences?

UPDATE:  I tried Winamp, and even though it's set to "Wave Out" (and there is no other option to pick) I still hear obvious gaps.  I'm using 5.2 -- what am I doing different such that you're hearing NO clicks, yet I'm still hearing entire gaps?

Thanks,

Larry

[Alex B]

I just tried Alex's test of the Beethoven mp3 files.  I could hear clicks on all but a couple of the quiet passages.  I didn't really notice any clicks on the louder passages, which (once again) I assume is because any clicks that might be there are masked.  I believe that of the "quieter" transitions, two of them had no noticeable click.

I edited the table to include the rest of track changes (approximately).

   time   MC                        foobar

  5.9 s  MC medium pop
10.2 s  MC medium Pop
15.7 s  MC loud pop         FB slight pop
20.7 s  MC slight pop
~25 s         -     no pops    -
30.4 s  MC medium pop
~35 s         -     no pops    -
(36.2 s  pop in the recording)
40.6 s  MC slight pop
45.6 s  MC medium pop
~50 s         -     no pops    -
~55 s         -     no pops    -
59.9 s  MC medium pop
~65 s         -     no pops    -
~70 s         -     no pops    -
75.5 s  MC slight pop
(77.1 s  pop in the recording)
80.7 s  MC loud pop

You could try to use MC's Disk Writer on your system and compare if the clicks you get are identical with those included in my output file. JRiver Media Editor is a better playback tool than MC because it has an accurate time display.

Alex -- What's your theory on why the other programs don't produce any noticeable clicks, and do you think this is something that's "fixable," or is it just a "luck of the draw" situation where some decoding engines are just different than others, which leads to these differences?

My lucky guess is that this is somehow related to the file length. So far the longer files I have tried have been very good. I seriously hope Matt can find a fixable bug. These kind of short files are not so uncommon. I have many albums that have short separate ungapped tracks (interludes, intros, applauses, outros etc).

UPDATE:  I tried Winamp, and even though it's set to "Wave Out" (and there is no other option to pick) I still hear obvious gaps.  I'm using 5.2 -- what am I doing different such that you're hearing NO clicks, yet I'm still hearing entire gaps?

Hmm... I think further discussion about this should take place at Winamp forum, but JRiver guys may want to compare MC with it, so here are my settings: WaveOut: Buffer length 2000 ms, Prebuffer 0 ms, Buffer ahead 200 ms. Also, I hid my older third-party mp3 decoder plug-ins like in_mp3PRO.dll and in_mpg123.dll and disabled all track change related DSP.

BTW, did you install the full version? I have DirectSound and Disk Writer besides the WaveOut output plug-in.

[lalittle]

My lucky guess is that this is somehow related to the file length. So far the longer files I have tried have been very good. I seriuosly hope Matt can find a fixable bug. These kind of short files are not so uncommon. I have many albums that have short separate ungapped tracks (interludes, intros, applauses, outros etc).

I'm not sure I follow you here.  When you say "file length," are you talking about the "overall length" of a track?  It doesn't sound like this is what you mean, and in my experience the length of the track has no effect on how likely the transition is to make a click.  In my testing, "most" quiet songs -- regardless of length -- tend to produce an audible click at the transitions.  It's usually quite small, but it's audible.

BTW, did you install the full version? I have DirectSound and Disk Writer besides the WaveOut output plug-in.

I "think" I may have downloaded the "lite" version.

Thanks,

Larry

[Alex B]

I meant track duration. These short 5 s tracks produce audible gaps on 10 of the 16 track changes, but so far the Pink Floyd etc abums that I have tried have been fine (track duration > 1 minute). I have not extensively tested this with complete albums and my guess can be totally wrong.

Have you disabled track based replay gain? It can make audible effects on track changes.

[hit_ny]

Have you disabled track based replay gain? It can make audible effects on track changes.

Huh ?

Thought track based replay gain would keep the volume close between tracks, making it harder to spot differences.

[Alex B]

.... Also the track lengths are slightly different:

MC
85s 596 ms
3774787 samples @ 44100Hz
File size: 15 099 192 bytes

foobar
85s 800 ms
3783780 samples @ 44100Hz
File size: 15 135 164 bytes

Winamp 5.2
85s 800 ms
3783780 samples @ 44100Hz
File size: 15 135 164 bytes

Perhaps this means something. Winamp and foobar files have the same amount of samples.