Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Why is asunder so slow when sound juicer is fast?
1,704 views
Skip to first unread message
chris
May 23, 2012, 5:31:32 AM5/23/12
to
Any reason why two CD rippers perform so differently in terms of speed?
Sound juicer can rip a CD in <5min whereas Asunder takes 10-15min.
I've tried them both on Fedora 16 and LinuxMint 12 and the difference is
consistent.
Sound juicer can rip a CD in <5min whereas Asunder takes 10-15min.
I've tried them both on Fedora 16 and LinuxMint 12 and the difference is
consistent.
Message has been deleted
Nick Leverton
May 23, 2012, 8:09:48 AM5/23/12
to
tries to make sure the copy is read OK. Some rippers/encoders allow
you to configure this when they call cdrdao:
--paranoia-mode mode
Sets the correction mode for digital audio extraction. 0: No checking,
data is copied directly from the drive. 1: Perform overlapped reading to
avoid jitter. 2: Like 1 but with additional checks of the read audio
data. 3: Like 2 but with additional scratch detection and repair.
The extraction speed reduces from 0 to 3.
Nick
--
"The Internet, a sort of ersatz counterfeit of real life"
-- Janet Street-Porter, BBC2, 19th March 1996
Tony Houghton
May 23, 2012, 8:40:24 AM5/23/12
to
In <jpik2c$6d4$1...@leverton.org>,
digital copy. AIUI jitter is caused by timing flaws in the recording,
mastering and playback hardware. How can cdparanoia tell what flaws have
been recorded and correct for them? And any jitter is far more likely to
be introduced by burning a copy on a £10 drive or listening to it on a
cheap player. cdparanoia certainly can't predict that and correct for
it.
Why not assume the mastering was near enough jitter free and make exact
digital copies? Then you can copy it as many times as you like and all
you have to worry about is providing the player with as accurate a clock
as possible.
--
TH * http://www.realh.co.uk
Nick Leverton <ni...@leverton.org> wrote:
> --paranoia-mode mode
> Sets the correction mode for digital audio extraction. 0: No checking,
> data is copied directly from the drive. 1: Perform overlapped reading to
> avoid jitter. 2: Like 1 but with additional checks of the read audio
> data. 3: Like 2 but with additional scratch detection and repair.
> The extraction speed reduces from 0 to 3.
I don't understand how jitter correction can be applied when making a
> --paranoia-mode mode
> Sets the correction mode for digital audio extraction. 0: No checking,
> data is copied directly from the drive. 1: Perform overlapped reading to
> avoid jitter. 2: Like 1 but with additional checks of the read audio
> data. 3: Like 2 but with additional scratch detection and repair.
> The extraction speed reduces from 0 to 3.
digital copy. AIUI jitter is caused by timing flaws in the recording,
mastering and playback hardware. How can cdparanoia tell what flaws have
been recorded and correct for them? And any jitter is far more likely to
be introduced by burning a copy on a £10 drive or listening to it on a
cheap player. cdparanoia certainly can't predict that and correct for
it.
Why not assume the mastering was near enough jitter free and make exact
digital copies? Then you can copy it as many times as you like and all
you have to worry about is providing the player with as accurate a clock
as possible.
--
TH * http://www.realh.co.uk
Dave
May 23, 2012, 11:21:30 AM5/23/12
to
Tony Houghton wrote:
> I don't understand how jitter correction can be applied when making a
> digital copy. AIUI jitter is caused by timing flaws in the recording,
> mastering and playback hardware. How can cdparanoia tell what flaws have
> been recorded and correct for them? And any jitter is far more likely to
> be introduced by burning a copy on a £10 drive or listening to it on a
> cheap player. cdparanoia certainly can't predict that and correct for
> it.
>
> Why not assume the mastering was near enough jitter free and make exact
> digital copies? Then you can copy it as many times as you like and all
> you have to worry about is providing the player with as accurate a clock
> as possible.
From http://en.wikipedia.org/wiki/Jitter:
> I don't understand how jitter correction can be applied when making a
> digital copy. AIUI jitter is caused by timing flaws in the recording,
> mastering and playback hardware. How can cdparanoia tell what flaws have
> been recorded and correct for them? And any jitter is far more likely to
> be introduced by burning a copy on a £10 drive or listening to it on a
> cheap player. cdparanoia certainly can't predict that and correct for
> it.
>
> Why not assume the mastering was near enough jitter free and make exact
> digital copies? Then you can copy it as many times as you like and all
> you have to worry about is providing the player with as accurate a clock
> as possible.
"In the context of digital audio extraction from Compact Discs, seek jitter
causes extracted audio samples to be doubled-up or skipped entirely if the
Compact Disc drive re-seeks. The problem occurs because the Red Book does
not require block-accurate addressing during seeking. As a result, the
extraction process may restart a few samples early or late, resulting in
doubled or omitted samples. These glitches often sound like tiny repeating
clicks during playback. A successful approach to correction in software
involves performing overlapping reads and fitting the data to find overlaps
at the edges. Most extraction programs perform seek jitter correction. CD
manufacturers avoid seek jitter by extracting the entire disc in one
continuous read operation, using special CD drive models at slower speeds so
the drive does not re-seek."
--
Dave
Tony Houghton
May 23, 2012, 3:51:05 PM5/23/12
to
In <4fbd007b$0$7316$5b6a...@news.zen.co.uk>,
taken at irregular intervals due to an inconsistent/inaccurate clock. I
can't remember where I read it, but I think the context had soemthing to
do with MPEG.
Dave <da...@cyw.uklinux.net> wrote:
> Tony Houghton wrote:
>
>> I don't understand how jitter correction can be applied when making a
>> digital copy. AIUI jitter is caused by timing flaws in the recording,
>> mastering and playback hardware.
>
> Tony Houghton wrote:
>
>> I don't understand how jitter correction can be applied when making a
>> digital copy. AIUI jitter is caused by timing flaws in the recording,
>> mastering and playback hardware.
>
> From http://en.wikipedia.org/wiki/Jitter:
>
> "In the context of digital audio extraction from Compact Discs, seek jitter
> causes extracted audio samples to be doubled-up or skipped entirely if the
> Compact Disc drive re-seeks.
Ah, I had read a different definition of jitter: meaning the samples are
>
> "In the context of digital audio extraction from Compact Discs, seek jitter
> causes extracted audio samples to be doubled-up or skipped entirely if the
> Compact Disc drive re-seeks.
taken at irregular intervals due to an inconsistent/inaccurate clock. I
can't remember where I read it, but I think the context had soemthing to
do with MPEG.
chris
May 24, 2012, 4:20:43 AM5/24/12
to
On 23/05/2012 13:09, Nick Leverton wrote:
> In article<jpiapk$usa$1...@dont-email.me>, chris<ithi...@gmail.com> wrote:
>> Any reason why two CD rippers perform so differently in terms of speed?
>> Sound juicer can rip a CD in<5min whereas Asunder takes 10-15min.
>>
>> I've tried them both on Fedora 16 and LinuxMint 12 and the difference is
>> consistent.
>
> Paranoia mode, perhaps ? It determines how hard the CD reader process
> tries to make sure the copy is read OK. Some rippers/encoders allow
> you to configure this when they call cdrdao:
>
> --paranoia-mode mode
> Sets the correction mode for digital audio extraction. 0: No checking,
> data is copied directly from the drive. 1: Perform overlapped reading to
> avoid jitter. 2: Like 1 but with additional checks of the read audio
> data. 3: Like 2 but with additional scratch detection and repair.
> The extraction speed reduces from 0 to 3.
Possibly. How does one tell, though?
> In article<jpiapk$usa$1...@dont-email.me>, chris<ithi...@gmail.com> wrote:
>> Any reason why two CD rippers perform so differently in terms of speed?
>> Sound juicer can rip a CD in<5min whereas Asunder takes 10-15min.
>>
>> I've tried them both on Fedora 16 and LinuxMint 12 and the difference is
>> consistent.
>
> Paranoia mode, perhaps ? It determines how hard the CD reader process
> tries to make sure the copy is read OK. Some rippers/encoders allow
> you to configure this when they call cdrdao:
>
> --paranoia-mode mode
> Sets the correction mode for digital audio extraction. 0: No checking,
> data is copied directly from the drive. 1: Perform overlapped reading to
> avoid jitter. 2: Like 1 but with additional checks of the read audio
> data. 3: Like 2 but with additional scratch detection and repair.
> The extraction speed reduces from 0 to 3.
These are Gnome programs and a plethora of options is not Gnome's forte.
Soundjuicer only gives you options to control the audio output settings,
not CD reading. IIRC Asunder is the same.
Jim Lesurf
May 24, 2012, 3:49:29 AM5/24/12
to
In article <slrnjrqf...@realh.co.uk>, Tony Houghton <h...@realh.co.uk>
wrote:
That meaning of jitter is commonly used in 'hifi' as they tend to be
thinking about clock and data waveform effects on the regularity of bit
transfer streams. So it crops up in consumer audio magzines, etc. But this
is another example of where people in slightly different contexts use the
same word to mean different things.
As Dave has pointed out: In reading audio CDs the system/spec lets an
attempt to read a given block of data return a block that is 'offset' by an
unpredictable number of sample/bit-slots. So to try and detect and correct
you have to do some retries and let your requested blocks 'overlap' with
others so you can check and shift alignments.
The original Red Book assumed a disc was being read in a 1x stream, and
that it didn't matter if the read started a few samples late or early. The
assumption was a standard CD player, not being read on a computer. The
player servos are assumed to be able to keep tracking and not lose data
(once error correction layers are used) whilst playing.
Slainte,
Jim
--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
wrote:
thinking about clock and data waveform effects on the regularity of bit
transfer streams. So it crops up in consumer audio magzines, etc. But this
is another example of where people in slightly different contexts use the
same word to mean different things.
As Dave has pointed out: In reading audio CDs the system/spec lets an
attempt to read a given block of data return a block that is 'offset' by an
unpredictable number of sample/bit-slots. So to try and detect and correct
you have to do some retries and let your requested blocks 'overlap' with
others so you can check and shift alignments.
The original Red Book assumed a disc was being read in a 1x stream, and
that it didn't matter if the read started a few samples late or early. The
assumption was a standard CD player, not being read on a computer. The
player servos are assumed to be able to keep tracking and not lose data
(once error correction layers are used) whilst playing.
Slainte,
Jim
--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html
Nick Leverton
May 24, 2012, 1:37:16 PM5/24/12
to
In article <jpkr0p$20f$3...@dont-email.me>, chris <ithi...@gmail.com> wrote:
>On 23/05/2012 13:09, Nick Leverton wrote:
>>
>> --paranoia-mode mode
>> Sets the correction mode for digital audio extraction. 0: No checking,
>> data is copied directly from the drive. 1: Perform overlapped reading to
>> avoid jitter. 2: Like 1 but with additional checks of the read audio
>> data. 3: Like 2 but with additional scratch detection and repair.
>> The extraction speed reduces from 0 to 3.
>
>Possibly. How does one tell, though?
When it's ripping, do a ps of the reader process. Assuming it's cdrdao
>On 23/05/2012 13:09, Nick Leverton wrote:
>>
>> --paranoia-mode mode
>> Sets the correction mode for digital audio extraction. 0: No checking,
>> data is copied directly from the drive. 1: Perform overlapped reading to
>> avoid jitter. 2: Like 1 but with additional checks of the read audio
>> data. 3: Like 2 but with additional scratch detection and repair.
>> The extraction speed reduces from 0 to 3.
>
>Possibly. How does one tell, though?
then "ps lww -C cdrdao" will tell what options it's been invoked with.
If that's not it then pstree should tell you what other software is
being called by SJ or Asunder.
>These are Gnome programs and a plethora of options is not Gnome's forte.
>Soundjuicer only gives you options to control the audio output settings,
>not CD reading. IIRC Asunder is the same.
so can't advise there I'm afraid.
0 new messages