Small Pop between tracks using Lame VBR- V-0
I am ripping with EAC and encoding with Lame, (version 3.98). 99% of the time I get a perfect transition between tracks that are suppose to be gapless (I.E Pink floyd albums) but I have a few tracks that have a very very small tick or pop from one track to the next. EAC said copy was 100% perfect. I am using Foobar for P.C playback.
As i said it is not between every track just the odd one or two. Does anyone have any ideas? I have tried various releases of lame and EAC the Glitch is always in the same spot it and is not showing up in the WAV file, only the encoded Lame file
Thanks.
Gapless playback without pops/clicks/etc. with lossy is not a guarantee. To make sure you don't have a problem with your EAC configuration, please post the contents of the log file. Make sure to encapsulate the contents of the log file in a codebox.
[codebox]...[/codebox]
Gapless playback without pops/clicks/etc. with lossy is not a guarantee. To make sure you don't have a problem with your EAC configuration, please post the contents of the log file. Make sure to encapsulate the contents of the log file in a codebox.
[codebox]...[/codebox]
When I get home from work tonight I will post an EAC log file but it's not EAC thats the problem it's the VBR Lame files. As per my 1st post the WAV files from EAC are perfect. I did read a post on Hydrogen audio that leads me to think it could be a VBR header thats to blame?
Thanks
If you rip it to a single file with cuesheet, then encode that file to MP3, you can split using pcutmp3 to generate a different kind of gapless information than LAME provides. Doing this might fix your problem.
Gapless playback without pops/clicks/etc. with lossy is not a guarantee. To make sure you don't have a problem with your EAC configuration, please post the contents of the log file. Make sure to encapsulate the contents of the log file in a codebox.
[codebox]...[/codebox]
EAC extraction logfile from 9. June 2010, 1:20 for CD
Andy Partridge & Harold Budd / Through The Hill
Used drive : ATAPI DVD A DH16A6L Adapter: 0 ID: 1
Read mode : Secure with NO C2, accurate stream, disable cache
Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Used output format : C:\Uberstandard Package - EAC - Lame\uberstandard\UberStandard\lame.exe (User Defined Encoder)
320 kBit/s
Additional command line options : -V 0 --vbr-new -q 0 -m s --add-id3v2 --pad-id3v2 --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d
Other options :
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Native Win32 interface for Win NT & 2000
Track 1
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\01 - Hand 19.wav
Peak level 74.3 %
Track quality 100.0 %
Copy CRC 1F7109A4
Copy OK
Track 2
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\02 - Through The Hill.wav
Peak level 59.5 %
Track quality 99.9 %
Copy CRC DC9AE384
Copy OK
Track 3
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\03 - Great Valley Of Gongs.wav
Peak level 54.9 %
Track quality 100.0 %
Copy CRC 8440658C
Copy OK
Track 4
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\04 - Western Island Of Apples.wav
Peak level 58.1 %
Track quality 100.0 %
Copy CRC 40A44FA4
Copy OK
Track 5
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\05 - Anima Mundi.wav
Peak level 72.1 %
Track quality 100.0 %
Copy CRC 1B677000
Copy OK
Track 6
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\06 - Hand 20.wav
Peak level 82.3 %
Track quality 100.0 %
Copy CRC A298EBC9
Copy OK
Track 7
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\07 - The Place Of Odd Glances.wav
Peak level 59.2 %
Track quality 100.0 %
Copy CRC D779E72D
Copy OK
Track 8
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\08 - Well For The Sweat Of The Moon.wav
Peak level 77.2 %
Track quality 100.0 %
Copy CRC 9071238D
Copy OK
Track 9
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\09 - Tenochtitlan's Numberless Bridges.wav
Peak level 73.1 %
Track quality 99.9 %
Copy CRC F703DA32
Copy OK
Track 10
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\10 - Ceramic Avenue.wav
Peak level 70.4 %
Track quality 100.0 %
Copy CRC 6A691ABE
Copy OK
Track 11
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\11 - Hand 21.wav
Peak level 56.7 %
Track quality 99.9 %
Copy CRC AE3B3295
Copy OK
Track 12
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\12 - Missing Pieces To The Game Of Salt And Onyx.wav
Peak level 66.3 %
Track quality 100.0 %
Copy CRC BCB99C36
Copy OK
Track 13
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\13 - Mantle Of Peacock Bones.wav
Peak level 83.8 %
Track quality 99.9 %
Copy CRC 148DF162
Copy OK
Track 14
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\14 - Bronze Coins Showing Genitals.wav
Peak level 81.8 %
Track quality 99.9 %
Copy CRC 01C0EF72
Copy OK
Track 15
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\15 - Bearded Aphrodite.wav
Peak level 74.0 %
Track quality 100.0 %
Copy CRC B1B010AB
Copy OK
Track 16
Filename C:\My MP3's\These MP3's Need To Be Taged\Andy Partridge & Harold Budd - 1994 - Through The Hill\16 - Hand 22.wav
Peak level 78.7 %
Track quality 100.0 %
Copy CRC 29B53A99
Copy OK
No errors occured
End of status report
Here is a log file from one of my rips
I missed the part about the wave files being ok.
Try Canar's solution. It's pretty well guaranteed to work.
With fb2k, yes, and since that's what the OP is using, it should indeed work fine.
However, any time pcutmp3 and gapless are mentioned together, I think the standard caveat should always be mentioned for the sake of other readers/future searches/etc: the pcutmp3-split files will very likely play gaplessly *only* in fb2k due to the unusually large padding value. iTunes, iPods, Winamp, etc. will usually have audible gaps when playing such files.
It's the gap detection go in EAC to: EAC --> Drive Options --> Gap Detection.
I'm using Detection Method A (Gap\Index Retrieval Method), Secure (Detection Accuracy).
That's the mode that in my drive doesn't introduces a tick on the begining of my rips... Test first changing the detection accuracy, if it works the problem is gone...
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009
EAC extraction logfile from 16. May 2010, 19:08
Pink Floyd / The Dark Side of the Moon
Used drive : Optiarc DVD RW AD-7190A Adapter: 0 ID: 0
Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : No
Make use of C2 pointers : No
Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : No
Used interface : Native Win32 interface for Win NT & 2000
Used output format : User Defined Encoder
Selected bitrate : 128 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Program Files\foobar2000\Encoders\wavpack.exe
Additional command line options : -w "Artist=%a" -w "Title=%t" -w "Album=%g" -w "Year=%y" -w "Track=%n" -w "Genre=%m" -h %s %d
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 3:56.47 | 0 | 17746
2 | 3:56.47 | 3:35.05 | 17747 | 33876
3 | 7:31.52 | 7:04.70 | 33877 | 65746
4 | 14:36.47 | 4:47.13 | 65747 | 87284
5 | 19:23.60 | 6:22.22 | 87285 | 115956
6 | 25:46.07 | 7:50.15 | 115957 | 151221
7 | 33:36.22 | 3:25.55 | 151222 | 166651
8 | 37:02.02 | 3:50.35 | 166652 | 183936
9 | 40:52.37 | 2:03.13 | 183937 | 193174
Range status and errors
Selected range
Filename D:\CDS\Pink Floyd\(1973) The Dark Side Of The Moon (1993 Remaster)\Pink Floyd - The Dark Side of the Moon.wav
Peak level 100.0 %
Range quality 100.0 %
Copy CRC EDE66179
Copy OK
No errors occurred
AccurateRip summary
Track 1 accurately ripped (confidence 2) [C9363CDC]
Track 2 accurately ripped (confidence 2) [6838F041]
Track 3 accurately ripped (confidence 2) [B75B0D5C]
Track 4 accurately ripped (confidence 2) [17CF8498]
Track 5 accurately ripped (confidence 2) [1B249DBE]
Track 6 accurately ripped (confidence 2) [23721A57]
Track 7 accurately ripped (confidence 2) [439B80B2]
Track 8 accurately ripped (confidence 2) [6D51A3EA]
Track 9 accurately ripped (confidence 2) [FF5D0D31]
All tracks accurately ripped
End of status report
It's the gap detection go in EAC to: EAC --> Drive Options --> Gap Detection.
I'm using Detection Method A (Gap\Index Retrieval Method), Secure (Detection Accuracy).
That's the mode that in my drive doesn't introduces a tick on the begining of my rips... Test first changing the detection accuracy, if it works the problem is gone...
Exact Audio Copy V0.99 prebeta 5 from 4. May 2009
EAC extraction logfile from 16. May 2010, 19:08
Pink Floyd / The Dark Side of the Moon
Used drive : Optiarc DVD RW AD-7190A Adapter: 0 ID: 0
Read mode : Secure
Utilize accurate stream : Yes
Defeat audio cache : No
Make use of C2 pointers : No
Read offset correction : 6
Overread into Lead-In and Lead-Out : No
Fill up missing offset samples with silence : Yes
Delete leading and trailing silent blocks : No
Null samples used in CRC calculations : No
Used interface : Native Win32 interface for Win NT & 2000
Used output format : User Defined Encoder
Selected bitrate : 128 kBit/s
Quality : High
Add ID3 tag : No
Command line compressor : C:\Program Files\foobar2000\Encoders\wavpack.exe
Additional command line options : -w "Artist=%a" -w "Title=%t" -w "Album=%g" -w "Year=%y" -w "Track=%n" -w "Genre=%m" -h %s %d
TOC of the extracted CD
Track | Start | Length | Start sector | End sector
---------------------------------------------------------
1 | 0:00.00 | 3:56.47 | 0 | 17746
2 | 3:56.47 | 3:35.05 | 17747 | 33876
3 | 7:31.52 | 7:04.70 | 33877 | 65746
4 | 14:36.47 | 4:47.13 | 65747 | 87284
5 | 19:23.60 | 6:22.22 | 87285 | 115956
6 | 25:46.07 | 7:50.15 | 115957 | 151221
7 | 33:36.22 | 3:25.55 | 151222 | 166651
8 | 37:02.02 | 3:50.35 | 166652 | 183936
9 | 40:52.37 | 2:03.13 | 183937 | 193174
Range status and errors
Selected range
Filename D:\CDS\Pink Floyd\(1973) The Dark Side Of The Moon (1993 Remaster)\Pink Floyd - The Dark Side of the Moon.wav
Peak level 100.0 %
Range quality 100.0 %
Copy CRC EDE66179
Copy OK
No errors occurred
AccurateRip summary
Track 1 accurately ripped (confidence 2) [C9363CDC]
Track 2 accurately ripped (confidence 2) [6838F041]
Track 3 accurately ripped (confidence 2) [B75B0D5C]
Track 4 accurately ripped (confidence 2) [17CF8498]
Track 5 accurately ripped (confidence 2) [1B249DBE]
Track 6 accurately ripped (confidence 2) [23721A57]
Track 7 accurately ripped (confidence 2) [439B80B2]
Track 8 accurately ripped (confidence 2) [6D51A3EA]
Track 9 accurately ripped (confidence 2) [FF5D0D31]
All tracks accurately ripped
End of status report
Its not the gap detection. Wav files ripped using the same settings and not encoded play perfectly with no gap or click between tracks.
It's the gap detection go in EAC to: EAC --> Drive Options --> Gap Detection.
Gap detection is quite different than the topic that's being discussed. We're talking about additional silence added to the beginning and ending of mp3 files, not the areas on a CD that are marked with a 00 index.
It's the gap detection go in EAC to: EAC --> Drive Options --> Gap Detection.
Gap detection is quite different than the topic that's being discussed. We're talking about additional silence added to the beginning and ending of mp3 files, not the areas on a CD that are marked with a 00 index.
Is there a Programm that will get rid of the additional silence? I wonder why it's only on a select few files?
It's the gap detection go in EAC to: EAC --> Drive Options --> Gap Detection.
Gap detection is quite different than the topic that's being discussed. We're talking about additional silence added to the beginning and ending of mp3 files, not the areas on a CD that are marked with a 00 index.
Is there a Programm that will get rid of the additional silence? I wonder why it's only on a select few files?
The small pop you hear is not related to additional silence. This silence is already eliminated by your player or else you would have much larger problems than small pops.
The small pop is due to separate encodes of the two tracks. The encoder is not matching the level at the end of the first track to the level at the start of the second track, thus the small pop at the junction of the two. The only sure way to eliminate this, as has been pointed out, is to encode them as a single track and then break the file up into separate tracks.
It's the gap detection go in EAC to: EAC --> Drive Options --> Gap Detection.
Gap detection is quite different than the topic that's being discussed. We're talking about additional silence added to the beginning and ending of mp3 files, not the areas on a CD that are marked with a 00 index.
Is there a Programm that will get rid of the additional silence? I wonder why it's only on a select few files?
The small pop you hear is not related to additional silence. This silence is already eliminated by your player or else you would have much larger problems than small pops.
The small pop is due to separate encodes of the two tracks. The encoder is not matching the level at the end of the first track to the level at the start of the second track, thus the small pop at the junction of the two. The only sure way to eliminate this, as has been pointed out, is to encode them as a single track and then break the file up into separate tracks.
Is there no other way to fix this problem? If this is common when encoding usin VBR then I am suprised that no one has come up with a fix.
Is there no other way to fix this problem? If this is common when encoding usin VBR then I am suprised that no one has come up with a fix.
VBR has nothing to do with it. CBR is just as likely to have the problem. This is an encoder issue, and I suspect that other codecs besides mp3 also suffer from it.
The problem is that the encoder's task is to make THIS file sound as much like the original as possible, and beginning or ending at a particular level is not a requirement.
If this is common when encoding usin VBR then I am suprised that no one has come up with a fix.
pdq gave you the correct answer (twice now), but you said it yourself, it isn't common...
99% of the time I get a perfect transition between tracks that are suppose to be gapless (I.E Pink floyd albums) but I have a few tracks that have a very very small tick or pop from one track to the next. EAC said copy was 100% perfect.
[...]
As i said it is not between every track just the odd one or two.
Is there no other way to fix this problem? If this is common when encoding usin VBR then I am suprised that no one has come up with a fix.
VBR has nothing to do with it. CBR is just as likely to have the problem. This is an encoder issue, and I suspect that other codecs besides mp3 also suffer from it.
The problem is that the encoder's task is to make THIS file sound as much like the original as possible, and beginning or ending at a particular level is not a requirement.
One of the solutions I think could help would be to encode the beginning and the end of the WAV file at maximum bitrate (320 kbps) if the WAV does not start/end with silence, when using VBR. This should improve the accuracy on file transitions and the bitrate increase would be negligible (if any).
Other codecs suffer from this problem too, except (in my experience) Ogg Vorbis at -q6 (or higher, I tested aoTuV version) because I was unable to find any artifacts on file transitions.
However, any time pcutmp3 and gapless are mentioned together, I think the standard caveat should always be mentioned for the sake of other readers/future searches/etc: the pcutmp3-split files will very likely play gaplessly *only* in fb2k due to the unusually large padding value. iTunes, iPods, Winamp, etc. will usually have audible gaps when playing such files.
Do you have evidence of this claim? I've never heard this. foobar2000 had to be modified to play them correctly, but I suspect that's only because Peter is such a stickler for details that he limited it to what he knew to be valid values.
One of the solutions I think could help would be to encode the beginning and the end of the WAV file at maximum bitrate (320 kbps) if the WAV does not start/end with silence, when using VBR. This should improve the accuracy on file transitions and the bitrate increase would be negligible (if any).
pcutmp3 does it perfectly, as it duplicates the data on either side of the transition. This should allow for gapless with no discontinuity ever, provided it's supported by the decoder.
[/quote]pcutmp3 does it perfectly, as it duplicates the data on either side of the transition. This should allow for gapless with no discontinuity ever, provided it's supported by the decoder.
[/quote]
pcutmp3 would seem to be the way to go but am having problems getting it installed
...and is not showing up in the WAV file, only the encoded Lame file
It may be helpful if you could upload some WAV samples to see if the problem can be reproduced, or for any possible clues within the samples. Like 10 seconds from each track on either side of a gapless transition where the problem exists. (be sure to mind the upload rule:
''No over 30 sec clips of copyrighted music.'')
Additional command line options : -V 0 --vbr-new -q 0 -m s
An observation apart from the gapless issue; Are you sure all of those commands are a good idea?
Additional command line options : -V 0 --vbr-new -q 0 -m s
An observation apart from the gapless issue; Are you sure all of those commands are a good idea?
-q0 is redundant, as values from 0-3 are equivalent under
--vbr-new.
-ms is never a good idea, but equally we'll never get a break from having to tell people that.
New Command line
-V0 --add-id3v2 --pad-id3v2 --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d
Click gone problem solved. Many thanks to those that tried to help.
Small Pop between tracks using Lame VBR- V-0
I am ripping with EAC and encoding with Lame, (version 3.98). 99% of the time I get a perfect transition between tracks that are suppose to be gapless (I.E Pink floyd albums) but I have a few tracks that have a very very small tick or pop from one track to the next. EAC said copy was 100% perfect. I am using Foobar for P.C playback.
As i said it is not between every track just the odd one or two. Does anyone have any ideas? I have tried various releases of lame and EAC the Glitch is always in the same spot it and is not showing up in the WAV file, only the encoded Lame file
Thanks.
I've run into commercial recordings that have DC offsets recorded into the data. If for some reason you have a transition from the DC offset track to a true 0 offset track, you will hear a small click at the transition. I'm an Audition guy and identifying/correcting offsets with Audition ( CoolEdit ) is incredibly easy. Other software is probably easy as well but I have no experience.
G²
But such a DC offset caused click would occur between the source WAV files too, which the OP stated does/did not occur. The problem has been identified as being due to LAME not accounting for any lossily-introduced difference between two tracks' last and first samples respectively.
andrew22690, I wonder how your new command line fixed the issue; it doesn't look to me to have anything that would affect this behaviour.
Additional command line options : -V 0 --vbr-new -q 0 -m s
An observation apart from the gapless issue; Are you sure all of those commands are a good idea?
-q0 is redundant, as values from 0-3 are equivalent under --vbr-new.
-ms is never a good idea, but equally we'll never get a break from having to tell people that.
What is the purpose of ms in the command line?
andrew22690, I wonder how your new command line fixed the issue; it doesn't look to me to have anything that would affect this behaviour.
Yes!!I got all exited when I couldn't hear the Gap/click, turns out it was still there, although very much reduced.
Additional command line options : -V 0 --vbr-new -q 0 -m s
An observation apart from the gapless issue; Are you sure all of those commands are a good idea?
-q0 is redundant, as values from 0-3 are equivalent under --vbr-new.
-ms is never a good idea, but equally we'll never get a break from having to tell people that.
What is the purpose of ms in the command line?
Nevermind I found it.
forced joint stereo
This mode will force MS joint stereo on all frames. It's slightly faster than joint stereo, but it should be used only if you are sure that every frame of the input file has very little stereo separation.Do you think this could mess up the gap?
What is the purpose of ms in the command line?
The -m s switch prevents lame from using mid/side encoding when it would improve sound quality, decrease file size, or both. Needless to say it should not be used.
forced joint stereo
This mode will force MS joint stereo on all frames. It's slightly faster than joint stereo, but it should be used only if you are sure that every frame of the input file has very little stereo separation.
Where on earth did you get this from? It is totally wrong. There is no such thing as "forced joint stereo".
What is the purpose of ms in the command line?
It forces the stereo mode to always be L/R stereo and prevents M/S stereo from ever being used.
But such a DC offset caused click would occur between the source WAV files too, which the OP stated does/did not occur. The problem has been identified as being due to LAME not accounting for any lossily-introduced difference between two tracks' last and first samples respectively.
andrew22690, I wonder how your new command line fixed the issue; it doesn't look to me to have anything that would affect this behaviour.
If there is a 0 offset segment between .WAV files that have a DC offset you'll hear 1 click at each boundary but if the files are simply 'played through' you'll hear no clicks at all. This gets into exactly how the the files are recorded onto the CD. If it IS a DC problem, it's quite easy to identify and repair.
To prove this to myself many years back I intentionally cut a .WAV file into 2 pieces with the cut boundary on a large peak and then made a CD with the files back to back with no added space. Surprise surprise, it played fine with no clicks. It's good to know how your equipment works.
G²
We're talking about consecutive tracks ripped from a gapless disc. There will be no DC issue.
Even if there are gaps between tracks and the disc was mastered so terribly that there are audible clicks resulting from DC shifts between tracks at normal listening levels, the likelihood that they occur exactly at the track transition is extremely slim.
Your raising concerns about DC level seems really out of place in this discussion.
Andrew, do you use the latest LAME release, version 3.98.4?
What is the purpose of ms in the command line?
I'd have thought you'd be able to tell us, since it was you who included it. It's a good idea to be aware of the purpose of an option before using it.
Nevermind I found it.
forced joint stereo
This mode will force MS joint stereo on all frames. It's slightly faster than joint stereo, but it should be used only if you are sure that every frame of the input file has very little stereo separation.
Do you think this could mess up the gap?
That explanation is for
-mf, not
-ms.
-ms forces simple stereo, which is inadvisable for reasons already given. And no, the stereo coding mode will have no effect on the gap issue
whatsoever.
the stereo coding mode will have no effect on the gap issue whatsoever.
I don't know that I'd say this, though I would not expect one setting to be consistently better or worse than the other.
It would be nice to have the samples available as requested earlier so that the effect of different encoding settings could be evaluated. The 15 last seconds of the first track and the 15 first seconds of the second track would be fine (naturally these must be cut from lossless source tracks).
the stereo coding mode will have no effect on the gap issue whatsoever.
I don't know that I'd say this, though I would not expect one setting to be consistently better or worse than the other.
That's a better way to put it. I think I must have been made overzealous by my crusade against simple stereo!
These are not original poster's samples but they have worked reliably for showing gapless issues for me. part 1 (http://www.saunalahti.fi/~cse/temp/gaptest1.flac) and part 2 (http://www.saunalahti.fi/~cse/temp/gaptest2.flac).
Gapless playback without pops/clicks/etc. with lossy is not a guarantee.
I think this statement is a little bold. The reported problem is due to the fact that LAME's gapless handling is incomplete. It is no necessary property of lossy encoding to suffer from this. The decoder needs complete information about how to reconstruct the original file's start and end. That's only very few samples. Additionally it needs exact length and offset information of the encoded data vs. the original. It just hasn't been implemented as good as it could.
I have never had trouble with Quicktime AAC files, but I don't know if it actually has a better implementation or if it is just such a rare phenomenon.
The reported problem is due to the fact that LAME's gapless handling is incomplete.
If you mean to say that its ability to tell the player which samples to play back and which to ignore as padding in incomplete, then your statement is nonsense. LAME does in fact provide "exact length and offset information of the encoded data vs. the original." If you mean that LAME is lacking some other method like overlapping encoded data as well as storing proper information to make sure the redundant part of the overlapped data is ignored to ensure the best possible transition (similar to the pcutmp3 approach, but for multiple tracks as the source), then yes there may be room for improvement.
Have you looked at the samples provided by Case above?
The issue isn't the number of samples, it is an audible discontinuity in amplitude between the last sample of one file and first sample of the next file. When I say first and last samples, I am not including padding. This problem is inherent in the nature of lossy encoding in general, not limited to LAME or any other particular lossy encoder.
It isn't like this hasn't been said before. Feel free to go back and read this discussion again.
Gapless playback without pops/clicks/etc. with lossy is
not a guarantee.
Andrew, do you use the latest LAME release, version 3.98.4?
Yes! 3.98.4 this is the Lame command I am using now -
V0 --add-id3v2 --pad-id3v2 --ta "%a" --tt "%t" --tg "%m" --tl "%g" --ty "%y" --tn "%n" %s %d. It hasn't totaly got rid of the click but it is now less obvious. From the Lame wiki site it has
%m that apparently should not be in there. should I just edit this out?
From the Lame wiki site it has %m that apparently should not be in there. should I just edit this out?
Why not just use -V0 %s %d and simply let EAC tag the files for you?
From the Lame wiki site it has %m that apparently should not be in there.
Did you assume this was related to the -m <stereo mode> switch? Let me explain why this conclusion is false.
For whatever reason, you have chosen to use LAME's command line tagging capability instead of letting EAC automatically handle the tagging. LAME's format for adding a genre tag is
--tg "genre".
%m is an EAC placeholder variable which will automatically insert the current genre data, that was entered in the main window, for the disc you're ripping (so we don't have to type specific metadata into the command line for each ripping session). So removing "%m" will only break genre tagging, if not the entire encoding process.
If you do not have a specific reason to use LAME's tagging capability instead of EAC's, you can follow greynol's advice - which also happens to echo the instructions in the hydrogenaudio wiki guide for EAC and LAME (http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame):
- If you wish to have EAC tag your files, you can safely tick Add ID3 tag; and in the Additional command line options box, copy and paste the following string:
-V0 %s %d
- If you wish not to have tags or prefer to have EAC pass along data so that Lame can do the tagging ...
[optional command lines]
I was thinking he found some article discouraging --tg "%m" because of problems which previous versions of Lame had when being passed an unrecognized genre. If you check the history for the wiki article you linked, you'll see we used to include a caveat about this.
I just want to make sure there aren't more articles in need of editing. If this Lame wiki article is not part of the Hydrogenaudio wiki (wiki.hydrogenaudio.org) or the official LAME web page (lame.sourceforge.net) then I'd actually prefer not to have it listed here. There are far too many guides giving sub-standard advice about Lame and/or EAC. They don't need any additional visibility. If this wiki article is part of HA then I'd like to know which one it is so that we can review it.
Here is the link to the wiki.
http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame (http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Lame)
Ok, so it would seem you need to read Trout's reply again.
Thank's Greynol now I get it.
Gapless playback without pops/clicks/etc. with lossy is not a guarantee.
I don't know why you focus on length and offset. I had said "additionally".. It would not take up to much space to save enough metadata for virtually lossless reconstruction of the first and last few samples, but that feature has obviously not been implemented, yet. For
any lossless codec this could be guaranteed, though, with sufficient effort.
Sorry by the mistake I missed the part "the Glitch is always in the same spot it and is not showing up in the WAV file, only the encoded Lame file".
Like the example provided by Case in this post (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=81991&view=findpost&p=714849) what I've always did when wanting to use mp3 via LAME when it doesn't encode perfectly gapless is to do a very short micro-seconds length fades on the problem tracks. The fades are so short it sounds gapless, even though it technically isn't.
For any lossless codec this could be guaranteed, though, with sufficient effort.
We aren't talking about lossless codecs; it seems from your post that you don't know of any lossy codecs. I'm not speaking for all of eternity, mind you, I'm commenting on the state of things today. I won't hold my breath on solutions, but I suppose it's fun to think of some.
I don't know why you focus on length and offset. I had said "additionally"
Additionally to what, this:
The decoder needs complete information about how to reconstruct the original file's start and end. That's only very few samples.
?
It didn't seem clear to me at the time that you talking about something other than length and offset. What do you propose about the transition from the area where there is complete information back to the area where there is no complete information? Are you suggesting some method of fading in and out some kind of fudge-factor?
I hope you realize that
every lossy codec in existence will need to have such a solution for my statement to be false.
We aren't talking about lossless codecs; it seems from your post that you don't know of any lossy codecs.
Sorry, it was a typo. The correct sentence would be:
For any lossy codec this could be guaranteed, though, with sufficient effort.
These are not original poster's samples but they have worked reliably for showing gapless issues for me. part 1 (http://www.saunalahti.fi/~cse/temp/gaptest1.flac) and part 2 (http://www.saunalahti.fi/~cse/temp/gaptest2.flac).
Thanks Case,
I tested the samples. They are fine for testing sample accurate decoding, but they don't cause the LAME MP3 encoding & decoding process to produce a waveform mismatch that would cause an audible effect like a click. I tried -V9, -V5 and -b 320. As expected, sample accurate decoding worked fine and there is no reason to believe that any audio data would cause it to fail.
We would need to have samples that would produce encoding artifacts that are strong enough to cause audible discrepancy at the track boundary.
They do produce a click. Listen again more closely and use headphones if necessary.
Small Pop between tracks using Lame VBR- V-0
I am ripping with EAC and encoding with Lame, (version 3.98). 99% of the time I get a perfect transition between tracks that are suppose to be gapless (I.E Pink floyd albums) but I have a few tracks that have a very very small tick or pop from one track to the next. EAC said copy was 100% perfect. I am using Foobar for P.C playback.
As i said it is not between every track just the odd one or two. Does anyone have any ideas? I have tried various releases of lame and EAC the Glitch is always in the same spot it and is not showing up in the WAV file, only the encoded Lame file
Thanks.
O.K I opened the file in Audacity, zoomed in and found there is a very small amount of silence at the end of the track. Is this silence the click?
If you rip it to a single file with cuesheet, then encode that file to MP3, you can split using pcutmp3 to generate a different kind of gapless information than LAME provides. Doing this might fix your problem.
This is the one and only guaranteed solution that I know of. Not sure what the three pages after this helpful post were hoping to produce. Unless you use pcutmp3, gapless does
not equal glitchless (except by good luck, which can be increased by using less lossy settings - this isn't a guarantee though!).
Cheers,
David.
They do produce a click. Listen again more closely and use headphones if necessary.
I tried both -V3 and -V3 -ms (Lame 3.98) and heard a definite click in the left channel at the transition.
Just finished encoding some of my problem tracks with Lame "-b320 %s %d " and on all the tracks the click is gone or reduced to a level that after multiple listening sessions I cannot hear it. Good enough...
They do produce a click. Listen again more closely and use headphones if necessary.
I just tried -b320 (Lame 3.98.4) and can still hear a click in the left channel at the transition.
These were on my own encoded files. Could be that the click was smaller to begin with?
I decided to try Andavari's idea (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=81991&view=findpost&p=714907) of short fading and it seems to work quite wonderfully. Pcutmp3 gives perfect gapless mp3 playback in foobar2000 but the files don't work properly on my portable players (iPods and Clip+).
I made a DSP component for foobar that automatically fades the beginning and end of tracks to silence and it gives me glitchless transition on all problem tracks I have tried so far. If you wish to try download Fake Gapless DSP (http://www.saunalahti.fi/~cse/foobar2000/foo_dsp_fakegapless.zip).
They do produce a click. Listen again more closely and use headphones if necessary.
I tried both -V3 and -V3 -ms (Lame 3.98) and heard a definite click in the left channel at the transition.
I have forgot to post that I revisited the samples and was able to hear the click with headphones when I knew exactly when the transition happens and what to expect then. Earlier I used desktop speakers and I didn't watch the computer screen so I didn't know exactly when the track changed. The faint high pitched click was masked by background noise, room acoustics and the loud cymbal crash that occurs only about 50 ms later. I must admit that I expected a more pronounced click or pop.
I wonder if a VBR encoder could have a mode that would use the maximum possible quality for the first and last frame (and maybe gradually change to the normal quality during a few following/preceding frames). It could make some track transition problems less pronounced without increasing the file size significantly.
I made a DSP component for foobar that automatically fades the beginning and end of tracks to silence and it gives me glitchless transition on all problem tracks I have tried so far. If you wish to try download Fake Gapless DSP (http://www.saunalahti.fi/~cse/foobar2000/foo_dsp_fakegapless.zip).
This is interesting. I don't have an archive of problem tracks, but I tried it with some gapless albums that have always played fine and at least I couldn't hear any adverse effect.
Here's 10 second clips of tracks that produce even more audible glitch that you will easily hear even with speakers. They are from tracks 1 and 2 of Misplaced Childhood by Marillion.
[attachment=6009:m1.flac]
[attachment=6010:m2.flac]
Here's 10 second clips of tracks that produce even more audible glitch that you will easily hear even with speakers. They are from tracks 1 and 2 of Misplaced Childhood by Marillion.
[attachment=6009:m1.flac]
[attachment=6010:m2.flac]
I don't hear any glitches when I play those 2 FLAC files in foobar, nor do I hear any when I convert them to MP3 V0320 and play them in foobar.
As soon as I tried V0, there was a small pop between them.
Odd.
...I convert them to MP3 V0320 and play them in foobar... Odd.
As there is no such thing, very! What are you talking about?
...I convert them to MP3 V0320 and play them in foobar... Odd.
As there is no such thing, very! What are you talking about?
I'm guessing he's talking about -V 0 -b 320?
Or just the common misconception that VBR quality levels equate to or should arrive at some definable (average) bitrate (often fuelled by estimates quoted by frontends), in this case -V0 and 320 kbps.
(often fuelled by estimates quoted by frontends), in this case -V0 and 320 kbps.
Maybe it depends which version of Foobar2000 he's using, but the two appear at different positions on the slider in V1.0.3 with V0 clearly marked as "~245kbps (*), V0" and the adjacent highest setting clearly marked as "320kbps CBR". It's impossible to confuse the two.
I wasn't implicating foobar2000.
Or any application, in this case, since a VBR file obviously can't have an average bitrate of 320 kbps.
I wasn't implicating foobar2000.
Or any application, in this case, since a VBR file obviously can't have an average bitrate of 320 kbps.
Well, sort of, since you can specify a VBR file with a minimum bitrate of 320 kbps. And, yes, you get a somewhat different file than a 320 kbps CBR encode.
I suppose I should have anticipated that, especially given the mention of -V0 -b320 earlier. However, the resulting file is not VBR in the typical sense sense that frames have or can have different bitrates, only that the bit reservoir is used differently or suchlike IIRC.
Maybe it depends which version of Foobar2000 he's using
He said he used foobar to play them, but never said what he used to convert them, specifically:
I don't hear any glitches when I play those 2 FLAC files in foobar, nor do I hear any when I convert them to MP3 V0320 and play them in foobar.
...and the speculation train rolls on.
I meant 320, the V0320 thing was a typo.
Basically: CBR MP3 = No pop
VBR V0 = pop
I don't hear any glitches when I play those 2 FLAC files in foobar, nor do I hear any when I convert them to MP3 V0320 and play them in foobar.
As soon as I tried V0, there was a small pop between them.
Those samples indeed seem to get enough quality boost from CBR, but my earlier Dimmu Borgir samples still click even with forced 320 kbps.
I have switched to using Fake Gapless DSP and recompressed all my lossy files from my FLACs with it enabled. I haven't yet heard a glitch with it enabled on my tracks.
I meant 320, the V0320 thing was a typo.
Basically: CBR MP3 = No pop
VBR V0 = pop
This is exactly my experience with VBR and CBR 320. I encode all my MP3's in CBR 320 now and No more Pops.
Maybe this is too much work, but has anyone tried altering the split point to coincide with the closest zero-crossing for both channels to reduce the problem? For me this would be a far better solution than bloating all the audio data with 320 kbit frames. Perhaps just a setting to force 320kbit frames on just transitions that have a lot of energy?
Pcutmp3 gives perfect gapless mp3 playback in foobar2000 but the files don't work properly on my portable players (iPods and Clip+).
Unless it's
rejecting the large enc_delay values from pcutmp3 (fb2k used to do that), I'm inclined to think that any player that claims to be gapless but chokes on pcutmp3 files is pretty hopeless.
My experience with my Clip+ and lame mp3s is that it's trying to have smaller gaps than my old Clip, but it would be a joke to call it gapless. I'm not worrying about the "right" way to make gapless files until the player demonstrates at least the possibility of doing things properly.
Cheers,
David.
Maybe this is too much work, but has anyone tried altering the split point to coincide with the closest zero-crossing for both channels to reduce the problem?
You mean before mp3 encoding? That could help a lot. You have to move beyond per-track encoding though - to encode track Y, you need the audio data from tracks X, Y and Z.
It would be possible to check where the mp3 frames would lie, keep the original track transition points (using approriate enc-delay and duration tag values) but fade out the audio between the "real" end of the track (given by enc_delay + duration) and the end of the final mp3 frame. That should encode far more cleanly.
You still need more than the current track's audio data though - once you get into that, you might as well just do it "properly".
For me this would be a far better solution than bloating all the audio data with 320 kbit frames. Perhaps just a setting to force 320kbit frames on just transitions that have a lot of energy?
Wouldn't that be fun to tune - for a given basic setting, when and how much should lame boost the bitrate on the first and last frames to avoid audible glitches. I think it's a great idea - maybe it can be made "good enough" on "the most commonly used settings" without too much work.
Cheers,
David.
For me this would be a far better solution than bloating all the audio data with 320 kbit frames. Perhaps just a setting to force 320kbit frames on just transitions that have a lot of energy?
Wouldn't that be fun to tune - for a given basic setting, when and how much should lame boost the bitrate on the first and last frames to avoid audible glitches. I think it's a great idea - maybe it can be made "good enough" on "the most commonly used settings" without too much work.
Do you really think that a couple of 320 kbps frames would increase the overall bitrate significantly? I suggested the use of 320 kbps frames over a month ago in this same thread:
I wonder if a VBR encoder could have a mode that would use the maximum possible quality for the first and last frame (and maybe gradually change to the normal quality during a few following/preceding frames). It could make some track transition problems less pronounced without increasing the file size significantly.
The first and last frames in the VBR mode would then always use -b 320 or what ever is the "safest" setting to produce clean track transitions. In case of the LAME encoder, probably the LAME developers would know what tricks if any would be needed for the few preceding/subsequent frames when the encoder changes to the normal VBR behavior. It could be named as a "safer gapless" switch or something like that.
However, Case's "Fake Gapless DSP" solution is brilliant. It seems to always work and if it has any effect to the resulting bitrate it will reduce it. That kind of DSP feature could be included in the LAME encoder. For now, foobar2000 + Fake Gaples DSP can be used for creating truly audibly gapless files.
EDIT: BTW, has anyone noticed this problem with AAC, Vorbis, or Musepack files?
Here is the transition point of the above posted samples (m1 and m2) encoded with lame 3.98.4 -V5 (~140 kbps):
http://i.com.ua/~alexeysp/mp3.png (http://i.com.ua/~alexeysp/mp3.png)
Here is the same transition of the same samples encoded with Vorbis aoTuVb5.7 -q2 (~96 kbps):
http://i.com.ua/~alexeysp/vorbis.png (http://i.com.ua/~alexeysp/vorbis.png)
The winner is quite obvious.
I've tried out the samples with LAME 3.98.4 at -V0 and LAME 3.97 at -V1 --vbr-new.
I found my LAME 3.98.4 encode has a very small pop at m2, but its abit hard for me to notice though. While my LAME 3.97 encode seems to decode the samples without any pops.