Re: Re: Re: Re: Re: More info please, Dragon Master.
i encourage you to use cdparanoia with a damaged disc. in my experience it has produced significantly better results.
bb
Charles Hansen said:
i encourage you to use cdparanoia with a damaged disc. in my experience it has produced significantly better results.
bb
There's also a DAC + noise reason with this.
Just a supposition, I think that there's something to do with the rest of the process. The normal CD reading mode is done with hardware, while the computer uses software, which is probably more accurate. It's a bit like : What do you prefer? Playing a 16/44.1kHz sound directly in your SBLive or resampling it to 16/48 first, 'cause you know the SBLive resamples. The CD is converted to PCM by hardware instead of just outputting raw data to the PC, letting it re-read, make sure there are no errors, and do all the process with software.
Just a supposition, I think that there's something to do with the rest of the process. The normal CD reading mode is done with hardware, while the computer uses software, which is probably more accurate. It's a bit like : What do you prefer? Playing a 16/44.1kHz sound directly in your SBLive or resampling it to 16/48 first, 'cause you know the SBLive resamples. The CD is converted to PCM by hardware instead of just outputting raw data to the PC, letting it re-read, make sure there are no errors, and do all the process with software.
DragonMaster said:
the data is already pcm (unfortunately) and i don't know about any upsampling (i certainly don't do any). of course, i don't play music straight from a pc to the stereo.
bb
b-square said:
Sorry, I misread your previous post and was thinking of a product like the Olive (Hifidelio) and not the SqueezeBox. Without doing a listening test one couldn't say which would be preferable. However based on my experience, I would expect that it would be easier to mitigate the electrical noise generated by the hard drive than from an entire computer (see below).
b-square said:
Yes, the noise will "leak through" unless the ground is totally (galvanically) isolated. The ethernet switch will not help here.
Re: Re: Re: Re: Re: Re: More info please, Dragon Master.
It is hard to do an apples-versus-oranges comparison here, but I will try. With a stand-alone CD player running at 1x, it is extremely rare for an uncorrected error to make it through the CIRC error correction. In the Stereophile article I linked earlier, Robert Harley only observed this when the scratch was 1mm or wider. This constitutes extremely severe damage.
When you say "better results", it's not clear what you are comparing CD Paranoia with. I suspect that much (if not all) of the improvement you are seeing is that multiple reads *do* produce better results when ripping the disc at 8x (or 24x or 52x or whatever speed you are using). At those high speeds it is much easier for uncorrected read errors to make it through.
So when trying to do high-speed ripping, then there would be an advantage to using multiple reads. It would allow error-free rips in a much shorter time. However, stand alone audio players will also achieve error free rips -- just at 1x. So in terms of "bit accuracy" there won't be any meaningful difference between a PC-based system and a standalone audio player.
b-square said:
It is hard to do an apples-versus-oranges comparison here, but I will try. With a stand-alone CD player running at 1x, it is extremely rare for an uncorrected error to make it through the CIRC error correction. In the Stereophile article I linked earlier, Robert Harley only observed this when the scratch was 1mm or wider. This constitutes extremely severe damage.
When you say "better results", it's not clear what you are comparing CD Paranoia with. I suspect that much (if not all) of the improvement you are seeing is that multiple reads *do* produce better results when ripping the disc at 8x (or 24x or 52x or whatever speed you are using). At those high speeds it is much easier for uncorrected read errors to make it through.
So when trying to do high-speed ripping, then there would be an advantage to using multiple reads. It would allow error-free rips in a much shorter time. However, stand alone audio players will also achieve error free rips -- just at 1x. So in terms of "bit accuracy" there won't be any meaningful difference between a PC-based system and a standalone audio player.
I will do a Test and connect my good old Mission DAC5 to a cd-Rom digital out and listen to it.
Can I connect it directly?
I read somewhere (here?) thet the level of the CD-Rom Drive is higher than the digital out of a CD-Player.
Is this right, and when it's right, does anybody know how to make it fit to my DAC5?
Cobra71
Can I connect it directly?
I read somewhere (here?) thet the level of the CD-Rom Drive is higher than the digital out of a CD-Player.
Is this right, and when it's right, does anybody know how to make it fit to my DAC5?
Cobra71
Cobra71 said:
The S/PDIF spec is 1 volt p-p (I think). Most CD-ROM drive digital outputs run at TTL levels and put out 5 volts p-p. However, this is not a problem in most cases. I have never heard of a DAC that couldn't accept a higher signal level. Many transports output signals higher than the S/PDIF spec.
The real problem is that the digital audio output on a CD-ROM drive typically (always?) has a terrible waveform. When you are building a ROM drive to the lowest possible price point, you aren't trying to get good performance from the digital audio output. They only do it to add the feature that allows connection to a soundcard. The signal comes directly from one of the LSI chips that runs the drive and has very low drive capability. The rise/fall times are so bad that the signal usually looks like a triangle wave. With biphase-mark encoding (as used with S/PDIF), a slow rise/fall time directly translates into data-correlated jitter.
On top of that you will have a direct galvanic connection between the ground of your computer and the ground of your hi-fi system. This will inject all sorts of electrical noise that will degrade the sonics.
The only advantage of doing this is that a ROM drive at $30 is cheaper than a $100 CD player. However, now you need a way to control the ROM drive. (Which is what this thread is about.)
Re: Re: Re: Re: Re: Re: Re: More info please, Dragon Master.
i mean better results in that discs that gave my cd player fits were successfully, if slowly, read cleanly by cdparanoia.
bb
Charles Hansen said:
i mean better results in that discs that gave my cd player fits were successfully, if slowly, read cleanly by cdparanoia.
bb
Charles Hansen said:
as i said, show me the measurements that indicate this noise is more significant than, say, my neighbor's wireless network or my fridge.
bb
Charles Hansen said:
Err, no. This thread is, as the title says, about extracting audio via the IDE port of a hard drive or a CDROM. There is a separate thread for simply controlling a CDROM via the IDE port.
May be this is interesting. Take a look here: http://oto-online.com/index.php?option=com_content&task=view&id=116&Itemid=49
G
(Sorry this is the wrong thread. Please delete it)
G
(Sorry this is the wrong thread. Please delete it)
This project was intended to build something a little more advanced : jitter-free I2S. The DSP would be coded to do digital audio extraction and output it with a CPU-clocked(a little over 700MHz IIRC) I2S output.
DESCRIPTION
Built on ESS’s proprietary and flexible Programmable
Multimedia Processor architecture, the VibrattoTM series of
DVD processors combine audio/video stream data
processing, system control and housekeeping functions
.
All of the Vibratto DVD processors each include two
parallel processing units, a RISC processor, a vector
engine, and supplemental hardware resources for
implementing specialized encoding and decoding tasks in
the device architectures. All of these resources are
interconnected with two separate data buses, each with its
own DMA unit and interface to external memory.
The processing units enable simultaneous parallel execution of
system commands and data processing.
Both the RISC processor and vector engine are
independently programmable. Each has its own on-chip
cache memory.
Audio
• Dolby Digital (AC-3), DVD-Audio, Pro Logic, DTS,
MPEG-1 layer 2 and 3 Audio (MP3), and High-Definition
Compatible Digital (HDCD) decoding
• On-chip Dolby Digital (AC-3) and DTS 5.1 channel
decoding and output (ES6018/28/38 Only)
• Dolby Digital and DTS S/PDIF digital audio output.
• Dolby Digital Class A, DTS, and HDCD certified
• Meridian Lossless Packing (MLP) decoding and Linear
PCM for DVD-Audio (ES6038 Only)
and most of all: It can accept external Audio Master Clock for audio DAC.
Built on ESS’s proprietary and flexible Programmable
Multimedia Processor architecture, the VibrattoTM series of
DVD processors combine audio/video stream data
processing, system control and housekeeping functions
.
All of the Vibratto DVD processors each include two
parallel processing units, a RISC processor, a vector
engine, and supplemental hardware resources for
implementing specialized encoding and decoding tasks in
the device architectures. All of these resources are
interconnected with two separate data buses, each with its
own DMA unit and interface to external memory.
The processing units enable simultaneous parallel execution of
system commands and data processing.
Both the RISC processor and vector engine are
independently programmable. Each has its own on-chip
cache memory.
Audio
• Dolby Digital (AC-3), DVD-Audio, Pro Logic, DTS,
MPEG-1 layer 2 and 3 Audio (MP3), and High-Definition
Compatible Digital (HDCD) decoding
• On-chip Dolby Digital (AC-3) and DTS 5.1 channel
decoding and output (ES6018/28/38 Only)
• Dolby Digital and DTS S/PDIF digital audio output.
• Dolby Digital Class A, DTS, and HDCD certified
• Meridian Lossless Packing (MLP) decoding and Linear
PCM for DVD-Audio (ES6038 Only)
and most of all: It can accept external Audio Master Clock for audio DAC.
ESS6008/18/28/38
Audio Interface
The audio interface is a bidirectional serial port that
connects to an external audio ADC/DAC for the transfer of
PCM (pulse coded modulation) audio data in I2S format. It
supports 16-, 24-, and 32-bit audio frames. No external
master clock is required(it can be configured work with external master clock). The Vibratto offers two audio
interface modes:
1. Stereo mode using TSD0 on pin 33.
2. Dolby™ Digital (AC-3) and DTS 5.1 channel mode
using TSD[2:0] on pins [37:36, 33]
The Vibratto audio mode configuration is selectable,
allowing it to interface directly with low-cost audio DACs
and ADCs. The audio port provides a standard I2S
interface input and output and S/PDIF (IEC958) audio
output. Stereo mode is in I2S format while six channel
Dolby™ Digital and DTS (5.1 channel) audio output can be
channeled through the I2S interface and S/PDIF.
The S/PDIF interface consists of a bi-phase mark encoder,
which has low skew. The transmit I2S interface supports
the 128, 192, 256, 384, and 512 sampling frequency
formats, where sampling frequency Fs is usually 32 kHz,
44.1 kHz, 48 kHz, 96 kHz, or 192 kHz. The audio samples
for the I2S transmit interface can be 16, 18, 20, 24, and 32-
bit samples.
For Linear PCM audio stream format, the Vibratto
supports 48 kHz and 96 kHz. Dolby Digital and DTS audio
only supports 48 kHz. The Vibratto incorporates a built-in
programmable analog PLL in the device architecture in
order to generate a master audio clock.
The MCLK pin is for the audio DAC clock and can either
be an output from or an input to the Vibratto. Audio data
out (TSD) and audio frame sync (TWS) are clocked out of
the Vibratto based on the audio transmit bit clock (TBCK).
Audio receive bit clock (RBCK) is used to clock in audio
data in (RSD) and audio receive frame sync (RWS).
Audio Interface
The audio interface is a bidirectional serial port that
connects to an external audio ADC/DAC for the transfer of
PCM (pulse coded modulation) audio data in I2S format. It
supports 16-, 24-, and 32-bit audio frames. No external
master clock is required(it can be configured work with external master clock). The Vibratto offers two audio
interface modes:
1. Stereo mode using TSD0 on pin 33.
2. Dolby™ Digital (AC-3) and DTS 5.1 channel mode
using TSD[2:0] on pins [37:36, 33]
The Vibratto audio mode configuration is selectable,
allowing it to interface directly with low-cost audio DACs
and ADCs. The audio port provides a standard I2S
interface input and output and S/PDIF (IEC958) audio
output. Stereo mode is in I2S format while six channel
Dolby™ Digital and DTS (5.1 channel) audio output can be
channeled through the I2S interface and S/PDIF.
The S/PDIF interface consists of a bi-phase mark encoder,
which has low skew. The transmit I2S interface supports
the 128, 192, 256, 384, and 512 sampling frequency
formats, where sampling frequency Fs is usually 32 kHz,
44.1 kHz, 48 kHz, 96 kHz, or 192 kHz. The audio samples
for the I2S transmit interface can be 16, 18, 20, 24, and 32-
bit samples.
For Linear PCM audio stream format, the Vibratto
supports 48 kHz and 96 kHz. Dolby Digital and DTS audio
only supports 48 kHz. The Vibratto incorporates a built-in
programmable analog PLL in the device architecture in
order to generate a master audio clock.
The MCLK pin is for the audio DAC clock and can either
be an output from or an input to the Vibratto. Audio data
out (TSD) and audio frame sync (TWS) are clocked out of
the Vibratto based on the audio transmit bit clock (TBCK).
Audio receive bit clock (RBCK) is used to clock in audio
data in (RSD) and audio receive frame sync (RWS).
Thread Review
Hey all,
Ok, I have skimmed the thread and just want to recap and clarify a few things. I think I can offer quite a bit to this thread. The reason I say this, is be cause I have successfully developed a CD player that extracts the digital audio from the drive via the IDE interface, and send this via a I2S stream to a SPDIF transmitter and DAC output.
Just so there is no confusion, I do NOT use the audio output on the drive, only the IDE interface. I have become very fimiliar with the ATAPI specification (and its problems). The design is actually for a commercial product, so i will NOT be posting the design details or code, but I am keen to clarify things and maybe get some ideas in return.
Ok, so assuming this thread is still on this track, I will talk about the controller speed. Many people have stated that you require a very fast micro, and someone said it is NOT possible with a ATmega. Well, fyi, my design SUCCESSFULLY operates with a ATmega running at 12MHz (was at 8MHz but I wanted a bit more speed just in case)!
You see, it is not that hard. All you need is a 16bit bus for the IDE, connected with an external RAM (i can explain why you need at least some RAM if someone wants), and with some tricky hardware you can generate the I2S stream. The micro does not need to actually "see" the data at all.
I have used a high quality oscillator which provides the MCLK for all clocks in the system, and therefore the drive has NOTHING to do with jitter. Jitter is ONLY a factor of your master clock, and since this is generated rather than provided, you have absolute control over the quality of the audio.
As for control, with such a system you have absolute control over the drive, so you can build what ever interface you like. I have Play, pause, FF, RW, SCANF, SCANR functions all working. The system can play CD-DA tracks on audio only, mixed mode and multisession discs with no problem. It also supports most drives out there from CDROM to DVD RW.
So, the reason I say all this, is mainly to clarify to everyone that it IS possible to do this, and to do it with a SIMPLE 8-bit micro. You dont need anything flash, and a DIYer can do it at home!
Cheers all,
Carl
Hey all,
Ok, I have skimmed the thread and just want to recap and clarify a few things. I think I can offer quite a bit to this thread. The reason I say this, is be cause I have successfully developed a CD player that extracts the digital audio from the drive via the IDE interface, and send this via a I2S stream to a SPDIF transmitter and DAC output.
Just so there is no confusion, I do NOT use the audio output on the drive, only the IDE interface. I have become very fimiliar with the ATAPI specification (and its problems). The design is actually for a commercial product, so i will NOT be posting the design details or code, but I am keen to clarify things and maybe get some ideas in return.
Ok, so assuming this thread is still on this track, I will talk about the controller speed. Many people have stated that you require a very fast micro, and someone said it is NOT possible with a ATmega. Well, fyi, my design SUCCESSFULLY operates with a ATmega running at 12MHz (was at 8MHz but I wanted a bit more speed just in case)!
You see, it is not that hard. All you need is a 16bit bus for the IDE, connected with an external RAM (i can explain why you need at least some RAM if someone wants), and with some tricky hardware you can generate the I2S stream. The micro does not need to actually "see" the data at all.
I have used a high quality oscillator which provides the MCLK for all clocks in the system, and therefore the drive has NOTHING to do with jitter. Jitter is ONLY a factor of your master clock, and since this is generated rather than provided, you have absolute control over the quality of the audio.
As for control, with such a system you have absolute control over the drive, so you can build what ever interface you like. I have Play, pause, FF, RW, SCANF, SCANR functions all working. The system can play CD-DA tracks on audio only, mixed mode and multisession discs with no problem. It also supports most drives out there from CDROM to DVD RW.
So, the reason I say all this, is mainly to clarify to everyone that it IS possible to do this, and to do it with a SIMPLE 8-bit micro. You dont need anything flash, and a DIYer can do it at home!
Cheers all,
Carl
The goal here is to have support for audio files as well. FLAC, OGG, MP3, etc.
Maybe the project could continue now as there is an ATAPI driver for Blackfin µcLinux.
Other processors could be looked at I guess. gmarsh works on Blackfins all the time so that's why he chose this DSP.
Blackfin supports a lot of serial formats through it's serial ports, I2S is one of them. I wonder if gmarsh wanted to use that one or generate the signal with software.
Maybe the project could continue now as there is an ATAPI driver for Blackfin µcLinux.
Other processors could be looked at I guess. gmarsh works on Blackfins all the time so that's why he chose this DSP.
Blackfin supports a lot of serial formats through it's serial ports, I2S is one of them. I wonder if gmarsh wanted to use that one or generate the signal with software.
- Status
- Not open for further replies.