PDA

View Full Version : Ripping Yarn



2004-08-05, 22:07
Jason wrote :

> Subject: [slim] Ripping Yarn
>
>
>>> ...
>>> I have a question about ripping.... I have ripped it using EAC, but
>> that gives distinct tracks with an intertrack gap when played.
>>>
>>> Is there a way to do it so that it is played contiguously on the
>>> slimp3/squeeze?
> > ...
>> The problem is mainly with the mp3 encoding (and possibly other
>> encoding schemes). The Lame faq discusses this.
>>
>> Newer versions of Lame implement "gapless" encoding, but it requires
>> you to encode manually. This is because EAC passes individual files
>> to the encoder, but gapless encoding requires Lame to peek at
>> adjacent wav files. So you have to pass all the files in sequence to
>> Lame. It is supposedly not quite perfect, but seems OK to me. SB and
>> Winamp play them seamlessly.
>
> I don't think this is the case any more. There used to be an old
> --nogap option that behaved the way you described. lame 3.90.3 and
> later write the actual size in bytes of the lame header+music portion
> of the mp3 into the lame header (MusicLength). A decoder can read this
> value and use it to achieve gapless playback. However not many
> decoders support this (foobar2000 is one that I know off-hand).
>
> Most formats designed after mp3 have better gapless support.

The options are still in 3.96, listed under --help (not as
experimental),
although they are not listed in the "full reference list" in
the Lame web pages, which suggests they are still experimental
after 3 years.

I presume that the SB does not support the technique based on header
content that you referred to, so we still need another way around it.
Or am I missing another option needed to make Lame write it?
Skimming through the Lame code, it isn't obvious to me
how it would avoid the problem of the extra padding
that creates the gap in the first place.

Cameron.

Graham Ridgway at home
2004-08-06, 13:27
well strangely, althoug I haven't had time to verify it, the slimp3 actually
seems to play the tracks back to back with no gap, so mysteriously it works
out of the box so to speak.
Graham
----- Original Message -----
From: <Cameron.Davidson (AT) csiro (DOT) au>
To: <discuss (AT) lists (DOT) slimdevices.com>
Sent: Friday, August 06, 2004 6:07 AM
Subject: [slim] Ripping Yarn


> Jason wrote :
>
> > Subject: [slim] Ripping Yarn
> >
> >
> >>> ...
> >>> I have a question about ripping.... I have ripped it using EAC, but
> >> that gives distinct tracks with an intertrack gap when played.
> >>>
> >>> Is there a way to do it so that it is played contiguously on the
> >>> slimp3/squeeze?
> > > ...
> >> The problem is mainly with the mp3 encoding (and possibly other
> >> encoding schemes). The Lame faq discusses this.
> >>
> >> Newer versions of Lame implement "gapless" encoding, but it requires
> >> you to encode manually. This is because EAC passes individual files
> >> to the encoder, but gapless encoding requires Lame to peek at
> >> adjacent wav files. So you have to pass all the files in sequence to
> >> Lame. It is supposedly not quite perfect, but seems OK to me. SB and
> >> Winamp play them seamlessly.
> >
> > I don't think this is the case any more. There used to be an old
> > --nogap option that behaved the way you described. lame 3.90.3 and
> > later write the actual size in bytes of the lame header+music portion
> > of the mp3 into the lame header (MusicLength). A decoder can read this
> > value and use it to achieve gapless playback. However not many
> > decoders support this (foobar2000 is one that I know off-hand).
> >
> > Most formats designed after mp3 have better gapless support.
>
> The options are still in 3.96, listed under --help (not as
> experimental),
> although they are not listed in the "full reference list" in
> the Lame web pages, which suggests they are still experimental
> after 3 years.
>
> I presume that the SB does not support the technique based on header
> content that you referred to, so we still need another way around it.
> Or am I missing another option needed to make Lame write it?
> Skimming through the Lame code, it isn't obvious to me
> how it would avoid the problem of the extra padding
> that creates the gap in the first place.
>
> Cameron.
>
>

Ken Veasey
2004-08-06, 14:37
As mentioned by Dean I find the gaps between tracks almost
undiscernible if only running one SB, but with two much more
noticeable, presumably because resynching is happening.


Ken


On Fri, 6 Aug 2004 21:27:13 +0100, you wrote:

>well strangely, althoug I haven't had time to verify it, the slimp3 actually
>seems to play the tracks back to back with no gap, so mysteriously it works
>out of the box so to speak.
>Graham
>----- Original Message -----
>From: <Cameron.Davidson (AT) csiro (DOT) au>
>To: <discuss (AT) lists (DOT) slimdevices.com>
>Sent: Friday, August 06, 2004 6:07 AM
>Subject: [slim] Ripping Yarn
>
>
>> Jason wrote :
>>
>> > Subject: [slim] Ripping Yarn
>> >
>> >
>> >>> ...
>> >>> I have a question about ripping.... I have ripped it using EAC, but
>> >> that gives distinct tracks with an intertrack gap when played.
>> >>>
>> >>> Is there a way to do it so that it is played contiguously on the
>> >>> slimp3/squeeze?
>> > > ...
>> >> The problem is mainly with the mp3 encoding (and possibly other
>> >> encoding schemes). The Lame faq discusses this.
>> >>
>> >> Newer versions of Lame implement "gapless" encoding, but it requires
>> >> you to encode manually. This is because EAC passes individual files
>> >> to the encoder, but gapless encoding requires Lame to peek at
>> >> adjacent wav files. So you have to pass all the files in sequence to
>> >> Lame. It is supposedly not quite perfect, but seems OK to me. SB and
>> >> Winamp play them seamlessly.
>> >
>> > I don't think this is the case any more. There used to be an old
>> > --nogap option that behaved the way you described. lame 3.90.3 and
>> > later write the actual size in bytes of the lame header+music portion
>> > of the mp3 into the lame header (MusicLength). A decoder can read this
>> > value and use it to achieve gapless playback. However not many
>> > decoders support this (foobar2000 is one that I know off-hand).
>> >
>> > Most formats designed after mp3 have better gapless support.
>>
>> The options are still in 3.96, listed under --help (not as
>> experimental),
>> although they are not listed in the "full reference list" in
>> the Lame web pages, which suggests they are still experimental
>> after 3 years.
>>
>> I presume that the SB does not support the technique based on header
>> content that you referred to, so we still need another way around it.
>> Or am I missing another option needed to make Lame write it?
>> Skimming through the Lame code, it isn't obvious to me
>> how it would avoid the problem of the extra padding
>> that creates the gap in the first place.
>>
>> Cameron.
>>
>>

dean
2004-08-06, 15:12
It's not that strange. SlimServer trys to send only valid MP3 frames
to the MP3 decoder in the players. That may mean that there was a
fractional frame that was dropped at the end or the beginning. This
might mean that samples are lost, but doesn't necessarily make the loss
audible.

On Aug 6, 2004, at 1:27 PM, Graham Ridgway at home wrote:

> well strangely, althoug I haven't had time to verify it, the slimp3
> actually
> seems to play the tracks back to back with no gap, so mysteriously it
> works
> out of the box so to speak.
> Graham
> ----- Original Message -----
> From: <Cameron.Davidson (AT) csiro (DOT) au>
> To: <discuss (AT) lists (DOT) slimdevices.com>
> Sent: Friday, August 06, 2004 6:07 AM
> Subject: [slim] Ripping Yarn
>
>
>> Jason wrote :
>>
>>> Subject: [slim] Ripping Yarn
>>>
>>>
>>>>> ...
>>>>> I have a question about ripping.... I have ripped it using EAC,
>>>>> but
>>>> that gives distinct tracks with an intertrack gap when played.
>>>>>
>>>>> Is there a way to do it so that it is played contiguously on the
>>>>> slimp3/squeeze?
>>>> ...
>>>> The problem is mainly with the mp3 encoding (and possibly other
>>>> encoding schemes). The Lame faq discusses this.
>>>>
>>>> Newer versions of Lame implement "gapless" encoding, but it requires
>>>> you to encode manually. This is because EAC passes individual files
>>>> to the encoder, but gapless encoding requires Lame to peek at
>>>> adjacent wav files. So you have to pass all the files in sequence to
>>>> Lame. It is supposedly not quite perfect, but seems OK to me. SB and
>>>> Winamp play them seamlessly.
>>>
>>> I don't think this is the case any more. There used to be an old
>>> --nogap option that behaved the way you described. lame 3.90.3 and
>>> later write the actual size in bytes of the lame header+music portion
>>> of the mp3 into the lame header (MusicLength). A decoder can read
>>> this
>>> value and use it to achieve gapless playback. However not many
>>> decoders support this (foobar2000 is one that I know off-hand).
>>>
>>> Most formats designed after mp3 have better gapless support.
>>
>> The options are still in 3.96, listed under --help (not as
>> experimental),
>> although they are not listed in the "full reference list" in
>> the Lame web pages, which suggests they are still experimental
>> after 3 years.
>>
>> I presume that the SB does not support the technique based on header
>> content that you referred to, so we still need another way around it.
>> Or am I missing another option needed to make Lame write it?
>> Skimming through the Lame code, it isn't obvious to me
>> how it would avoid the problem of the extra padding
>> that creates the gap in the first place.
>>
>> Cameron.
>>
>>