PDA

View Full Version : CD transport into Apple Mac



Neil McCauley
10-07-2008, 10:23
Dear colleagues ...

I'm in ignorance about this and I seek enlightenment Is there any published evidence to support or contradict the view that the quality of the transport, when transferring onto an Apple Mac either via the on-board DAC or an external one influences the sound?

I'm in the process of investing in this. I’ll use my North Star 192 Transport (Philips PRO-2 mechanism) through my Benchmark and will transfer a few tracks and I’ll do the same with a cheap ‘n cheerful transport from eBay via the same route. However during the interim, useful links and observations will be grateful received. Thank you. Howard.


---//---

Filterlab
10-07-2008, 10:34
Well, I have an offboard drive which is vastly better than the built in drive (in terms of construction) in the Mac, I've imported using both drives and I can tell no difference whatsoever. Granted I haven't done a serious set of tests, but the Mac drive certainly seems to be an exceptional import drive when used with the right software.

To import I use Max (http://sbooth.org/Max/) which utilises CD Paranoia (http://xiph.org/paranoia/) - basically put it does as many passes as the user wishes (I go for three) and then compiles and averages that data for each track removing as much error correction work as possible and replacing it with the undamaged hard data from each pass of the disc. Great for injured CDs, not quite so necessary for perfectly unscratched CDs (i.e. mine).

However Howard, now you've got me thinking about it I may just sit down and do some back to back import tests to see if I can note any difference.

Marco
10-07-2008, 10:48
Howard,

Have you read the 'CD transports - do they matter?' thread?

If not, I think you should read it: http://theartofsound.net/forum/showthread.php?t=645

There are 'transports', and there are Transports, if you see my meaning.

When importing CDs to a hard drive, providing the computer used can accurately resolve the difference in the source signal, the quality of the transport most certainly does matter, just as it matters when playing a CD through a normal hi-fi system.

Why should it be any different?

The goal is still maximum resolution and faithfulness to the source music.

And a cheapo transport will lose information or add more coloration to the signal than something seriously good, like my Sony or others of its ilk. The key thing here is to successfully differentiate between what constitutes as a top-notch transport mechanism and what doesn't. IMO, 95% of what's made these days doesn't. I'm not even sure, despite being better than most, if the Philips PRO-2 in your North Star qualifies as 'top-notch'.

Marco.

P.S Is the valves thread we discussed imminent? I'm rather looking forward to that one :)

Neil McCauley
10-07-2008, 11:36
Well, I have an offboard drive which is vastly better than the built in drive (in terms of construction) in the Mac, I've imported using both drives and I can tell no difference whatsoever. Granted I haven't done a serious set of tests, but the Mac drive certainly seems to be an exceptional import drive when used with the right software.

To import I use Max (http://sbooth.org/Max/) which utilises CD Paranoia (http://xiph.org/paranoia/) - basically put it does as many passes as the user wishes (I go for three) and then compiles and averages that data for each track removing as much error correction work as possible and replacing it with the undamaged hard data from each pass of the disc. Great for injured CDs, not quite so necessary for perfectly unscratched CDs (i.e. mine).

However Howard, now you've got me thinking about it I may just sit down and do some back to back import tests to see if I can note any difference.
Thank you. Very helpful indeed. i am most appreciative. This forum yet again proves, if indeed any proof were needed, its value!

Filterlab
10-07-2008, 11:42
My pleasure, I'm glad my experiences can be of help. :)

Neil McCauley
10-07-2008, 11:45
P.S Is the valves thread we discussed imminent? I'm rather looking forward to that one :) - said Marco

============

Re the valves thread, this is what I have in mind:

1976 to 1988: To include direct personal experiences with Audio Research, Conrad Johnson, Beard, EAR, Radford and Michaelson Austin / TVA. The highs, the lows, the danger (from equipment and paranoid importers) and my disenchantment with the who silly valve thing.

2005 to 2008: To include direct personal experiences with Audio Research (curiously positive) Manley, and the reversal of my disenchantment with the who silly valve thing.

Might take me a few days to get my act together on this one. Contemporaneous notes to find and then refer to, missing brain cells to be located, plugged in and tested, fretful customers to look after, and stuff like that.

Meanwhile, as for the missing years 1999 to 2004, they were valve-less, fun-less and ultimately lucrative. You can read about it here: http://www.stereonow.co.uk/history.html


---//---

Marco
10-07-2008, 12:03
Sounds great, Howard - no rush :)

Valves are a hot topic at the moment and I think the forum would benefit from hearing your 'take' on it, based on obviously extensive experience. What intrigues me most is the disappointment you've had with some of the famous hi-end brands such as CJ, etc. This mirrors my own experience, and in some cases what I heard still continues in that area of the valve amplifier market today.

Where it's 'at' now, valve-wise, is what's available from small specialist manufacturers, and the Chinese. And of course, D.I.Y!

Manley products could do with some serious plugging. It's little known (to most people) but excellent. Their entry-level stuff offers particularly high sound-per-pound value.

I'll leave the task in your capable hands!

Marco.

tfarney
10-07-2008, 14:51
If you're talking about getting data into the Mac, it shouldn't make a bit of difference if you use the data cd drive built into the Mini or the most expensive transport you can get your hands on. The error correction software will check the zeros and ones on the hard drive against the cd and sample as many times as it takes to ensure that they are a bit perfect match. The transport's stability is irrelevant at the end of the day. It may reduce the need to re-read, speeding up the process, but I've never noticed the process being anything but consistently quick, and I've ripped my entire library.

Tim

Tony Moore
10-07-2008, 15:58
Hi Howard,

Forgive me if I'm being dense but I don't quite understand how you intend to hook the CDPro2M up to your Mac to read audio data. As far as I'm aware the CDPro2m is just a redbook cd player mech with s/pdif and analogue outs, no parallel data for computer interface and control. If you mean to connect via s/pdif then yes, the quality of the transport and associated power supplies, s/pdif electronics, etc, will affect the sound quality.

As far as CDROM drives go, yes to a certain extent I'd agree that with multiple reads (EAC or similar) then it may be possible to eliminate most of the errors in reading from CD. Within reason! Some CDROM drives are total rubbish!

Anyway, CDPro2M is a good drive, streets ahead of most modern plastic mechs. 300 Euros gets you the drive module only, so once you add controller, display, power supplies and case any commercially made CD transport based on it would be expensive and therefore probably badged as "top notch".

Marco, I'll bring my CDPro2M along to ChesterFest and you can listen to it on your DAC if you like? I don't tend to use it much anymore though, now I use SqueezeBox3 and my TDA1541A based DAC. The SB3 and music server just fit in with our way of listening to music much better. AudioScrobbling, finding new music, LastFM etc.

This is my DAC and SB3 project:

http://i296.photobucket.com/albums/mm168/TonyMoore300B/DAC.jpg

This is a home built effort! :eyebrows: I'm using I2S to connect the SB3 to the TDA1541A for ultimate performance and eliminating the s/pdif connection. Also in there are Tent XO clock and a CPLD board to convert the format of the digital signal to the form needed for the TDA1541A.

I'll bring this along to the ChesterFest too if anyone's interested? :smoking:

Cheers,
Tony

Marco
10-07-2008, 16:35
Tim,


If you're talking about getting data into the Mac, it shouldn't make a bit of difference if you use the data cd drive built into the Mini or the most expensive transport you can get your hands on. The error correction software will check the zeros and ones on the hard drive against the cd and sample as many times as it takes to ensure that they are a bit perfect match.


I was under the impression that the more times it done this sound quality (in some ways) suffered. Perhaps I'm wrong, though.

Also, IMO, similarly when judging transport mechanisms on dedicated CD players, some reproduce the zeros and ones more 'accurately' than others (or rather some protect the 'integrity' or 'completeness' of the zeros and ones better than others) due to a host of factors, mainly to do with the engineering of the transport mechanism itself, the resonance properties of its construction, and how the data it reads remains intact and 'untainted' by any anomalies in the supporting hardware design before the signal reaches the next processing stage.

My view is that it's better to achieve the most accurate data retrieval of the music signal in the first place with the need for little, if any, error correction later, than the opposite. Every 'process' involved in reproducing the music signal has a knock-on effect on sound quality, so one should seek to minimise 'processes' where possible. This is fundamental hi-fi methodology and is implemented in the design of quality CD players and throughout audio.

If one is a true purist (and if you're not, why post on a specialist audio forum like this?) *everything* matters in *all* areas of music reproduction and I see no reason why one shouldn't seek to achieve the same goals detailed above with computer audio in general, and as far as this particular discussion is concerned, importing CDs to a hard drive.

That's why I believe quality transports make a difference in any digital audio application.

Marco.

Marco
10-07-2008, 16:55
Tony,


As far as CDROM drives go, yes to a certain extent I'd agree that with multiple reads (EAC or similar) then it may be possible to eliminate most of the errors in reading from CD. Within reason! Some CDROM drives are total rubbish!


I totally agree. It also goes against the grain, for me anyway, to use some cheap plastic transport design in any digital application - I would always use something solid and beautifully engineered even if it just felt nicer to use!


Marco, I'll bring my CDPro2M along to ChesterFest and you can listen to it on your DAC if you like?

Bring it on, Tony. I'd love to hear it and your own DAC, too - looks great :)

TDA1541 chips rule!!

Marco.

NRG
10-07-2008, 20:08
I think there is a bit of confusion here.

You can get CD based music onto the Mac/PC in two ways, play the analogue output from a CD player (high end Dedicated or whatever) into a soundcard (ADC) and store it on to the computer or perform Digital Audio Extraction of the CD data direct onto the harddrive.

DAE is by far the best way to go, it eliminates the DAC and ADC steps and also has the benefit of supporting C1 and C2 error correction and detection. Many many dedicated audio CD players do not perform C2 error correction.

Yes, it's true most Computer based CD players (well they are all now DVD players) are plastic things that play Red book CD via analogue in a most pitiful way but....they perform DAE in a very accurate and reliable manner and they will produce a better copy of an Audio CD using DAE than any high end dedicated audio CD player can because of the DAE process.

Oh and BTW I read it many times on the boards that the data from CD's are read as one's and zeros....not true, the data stream from the raw cd is not a square wave, it's more like an analogue signal or more accurately an RF sinusoidal EFM signal. But is does contain the information to reproduce the original data...

Marco
10-07-2008, 20:29
Yes, it's true most Computer based CD players (well they are all now DVD players) are plastic things that play Red book CD via analogue in a most pitiful way but....they perform DAE in a very accurate and reliable manner and they will produce a better copy of an Audio CD using DAE than any high end dedicated audio CD player can because of the DAE process.


Hi Neal,

What exactly is the DAE process?

I'm not qualified to dispute the above, but has anyone actually done the comparison and listened to the results?

You see, I'm an old-fashioned guy, and fancy technical terms and 'scientific facts' in audio mean little to me unless I hear the results myself through a hi-fi system with music. I don't automatically 'accept' any effect in audio until I have judged it through that process.

As such I would love to do a test using a top-notch Red Book CD transport and a computer based one in respect of the above to see if I could hear any difference in the results obtained. If I could genuinely hear no difference then I will have learned something and we will be in full agreement.

Perhaps we could do this at the Chesterfest? :)

Marco.

Mike
10-07-2008, 20:44
Hi Neal,

What exactly is the DAE process?



LOL!... Marco, think of it like this:

There is no music on a CD, only DATA, stored as one's and zero's. It only becomes music once processed by a DAC.

The trick here is to transfer that raw data as accurately as possible onto a hard drive, this is where multiple passes (the number of times the disk is read) and error detection and correction comes in. With DAE you can take as long as you need/want doing this process to get the data from the CD with as few (if any) errors as possible. An error is reading a '1' as a '0' and vice versa.

Listening to it 'live' or converting it in 'real time' (ie. as it's playing) is a different matter, the transport has only one chance to get it right, any error detection and correction has to be done 'on the fly'. A much more tricky prospect.

A very simplistic (and possibly rubbish) explanation.

Marco
10-07-2008, 20:50
No that's absolutely fine, Mike. I understand - cheers :)

I'd still like to *HEAR* the results myself, though (somehow).

How was yer sleep - any nice dreams? :eyebrows:

Marco.

Mike
10-07-2008, 20:59
How was yer sleep - any nice dreams? :eyebrows:

Marco.

No dreams that I can remember, slept like a dead body. Didn't get up till 5:30pm so I'll probably not be able to sleep tonight either. :doh:

Filterlab
11-07-2008, 08:52
LOL!... Marco, think of it like this:

There is no music on a CD, only DATA, stored as one's and zero's. It only becomes music once processed by a DAC.

The trick here is to transfer that raw data as accurately as possible onto a hard drive, this is where multiple passes (the number of times the disk is read) and error detection and correction comes in. With DAE you can take as long as you need/want doing this process to get the data from the CD with as few (if any) errors as possible. An error is reading a '1' as a '0' and vice versa.

Listening to it 'live' or converting it in 'real time' (ie. as it's playing) is a different matter, the transport has only one chance to get it right, any error detection and correction has to be done 'on the fly'. A much more tricky prospect.

A very simplistic (and possibly rubbish) explanation.

In fact that's an excellent explanation.

Half the problems with computer based audio is that many programs (iTunes included) import on a straight rip; i.e. importing the data once and running it through an error correction system - the same as a straight replay from a CD player. With certain import programs, programs that are specifically designed for complete error free importing (like Max), multiple passes of the CD are taken. The software then averages the data omitting any data that isn't original (error corrected data for example) and replacing it with the true data from another pass.

To put it another way, if you have ten identical cars all with some damage on them, by using only the good parts from each car one should easily be able to make a perfect car with no faults. This is what multiple pass software does. Of course, most CDs owned by audiophiles are unlikely to have damage extensive enough on them to require more than three passes, but in the case of buying secondhand CDs up to ten may be necessary to get as clearer data as possible.

This is where imported music has a distinct advantage over a CD player, a CD player is doing everything on the fly, reading the disc, coping with external forces, correcting errors with what it 'thinks' should be in place, sending the data to the DAC, decoding in the DAC and converting the signal to analogue. In essence it's like asking a musician to play a tune whilst it's still being written by the composer rather than the composer providing a printed sheet of music.

This is why the quality of the transport used for import is not as critical as one used for immediate replay. The CD player has one chance to get it right and must do it time and time again with as few errors as possible, an import on the other hand may take several minutes as might the decoding process, but it has multiple times to look at the data and get it perfect (or as perfect as) before finalising it in the form of a stream of correct 1s & 0s. Once this has occured the reading of it is faultless EVERY time and there's no mechanical interface to interfere with its replay.

Marco
11-07-2008, 08:59
Another excellent explanation. Thanks for that, Rob.

All seems clear, but I'd still like to do the test though, as I've outlined, to hear whether in reality what you're saying is actually the case. Sorry, it's just the way I am :)

Marco.

P.S Did you get my mail about the smileys?

Filterlab
11-07-2008, 09:02
Another excellent explanation. Thanks for that, Rob.

All seems clear, but I'd still like to do the test though, as I've outlined, to hear whether in reality what you're saying is actually the case. Sorry, it's just the way I am :)

Marco.

P.S Did you get my mail about the smileys?

Well, for me it took actually hearing it to nail the revelation home - you were there at the time. :) Since then though I've learnt a lot more about the subject and had the chance to try oodles of different combinations of software that's made the world of difference.

Yep, got your email. Replied twice but it just bounces back. Have you got the trampoline out again?

NRG
11-07-2008, 09:10
Hi Neal,

What exactly is the DAE process?

I'm not qualified to dispute the above, but has anyone actually done the comparison and listened to the results?

You see, I'm an old-fashioned guy, and fancy technical terms and 'scientific facts' in audio mean little to me unless I hear the results myself through a hi-fi system with music. I don't automatically 'accept' any effect in audio until I have judged it through that process.

As such I would love to do a test using a top-notch Red Book CD transport and a computer based one in respect of the above to see if I could hear any difference in the results obtained. If I could genuinely hear no difference then I will have learned something and we will be in full agreement.

Perhaps we could do this at the Chesterfest? :)

Marco.

Mike has nailed it pretty much Marco. And no offence but you are a Luddite :lolsign:

It's not scientific fact, it's common sense....keeping the digital data in the digital domain for transfers is the best way to go. Each time you perform ADC and then DAC you will introduce errors, noise artifacts etc.

If you believe in the 'simple chain is best' rule for audio quality and the 'rubbish in = rubbish out' philosophy then you'll see DAE is the only way to go for the best copy and therefore best sound quality when ripping to HDD. :cool:

Marco
11-07-2008, 09:11
Well, for me it took actually hearing it to nail the revelation home - you were there at the time. :)


Indeed :)

But that was only with some bollocks NAD CD player which is a million miles away from what I use. Besides that's different to what I'm on about. What if the original rip was carried out from a top-notch CD transport instead of the computer one and then the resulting rip reproduced losslessly through the computer?

It's that specific part of the process (the original import) I remain to be convinced about, not the efficacy of computers in general (when streaming lossless files) being a high quality source of recorded music. I'm not saying Neal or you are wrong, in fact in this instance it's probably me that's wrong, but I just need to hear it for myself.


Since then though I've learnt a lot more about the subject and had the chance to try oodles of different combinations of software that's made the world of difference.


Undoubtedly, and I've seen ample evidence of this. It's also good that you're obviously enjoying your music now more than ever. I just need to hear the effect with my lugs using a familiar (top-notch) reference before I will accept it - always the subjectivist, me! ;)


Yep, got your email. Replied twice but it just bounces back. Have you got the trampoline out again?

No idea why that's happening. Everything seems ok at my end. Can you PM me your reply?

Marco.

NRG
11-07-2008, 10:06
You can't 'rip' from a dedicated audio CD player like your Sony Marco.

You have to play the CD in real time, perform DAC feed analogue signal into a sound card and then perform ADC to get a WAV file.

Marco
11-07-2008, 10:15
I know, perhaps I didn't explain myself clearly. I meant using a top-notch CD transport for the source music (the playing of the CD in real time) instead of a computer-based one.

Marco.

Tony Moore
11-07-2008, 10:33
Marco, it would be great to use a top notch transport to rip to a computer but there is a fundamental difference in the way that dedicated red book CD transports (non CDROM drives) extract and format the data. CDROM drives support Direct Audio Extraction (DAE) which enables the audio data to be pre-converted (in the drive) into computer data words for the operating system to save to files, output to DACs, etc. Programs like EAC use the DAE mode to get the audio data off the CD, keeping everything digital. In the old days before CDROM drives had DAE mode the CDROM drive used to pass the audio signal direct from it's own inbuilt (cheap) DAC to the PCs sound card which then usually sent it through a mixer and out to the speakers. Sometime later some sound cards also had s/pdif input which then could be connected to the CDROM drive to get the signal via s/pdif, so digital but still prone to poorer quality than DAE.

There are obviously more advantages of DAE including accurate track lengths and spacing which I assume the CDDB and likes use for the generation of the ident to get the tagging information from their database.

The thing is, how well does the CDROM drive actually do the data extraction (in redbook mode) and conversion to data? Is it possible to get bad data repeatedly and yet the error detection and correction system fills in the same wrong data each time? Then EAC would not know anything is wrong. I'm no expert in CDROM drives but I wonder if this is possible? The error detection system for PCM audio is fairly poor, not like the actual data reading modes and CDROM drive's mechanics are built to such a low cost...

As far as I know, the CDPro2M does not support DAE. And drives that do are probably mostly fairly cheap CDROM drives. So I think we're stuck!

I would love to be proved wrong though!

I have to say, the DVD writer drive that I use seems to work pretty well with EAC all things considered. The FLAC files played back through my SB3/DAC sound as good or better than the original CD played on the CDPro2M so I'm happy.

Cheers,
Tony

Marco
11-07-2008, 10:40
Thanks for that, Tony. Most interesting.


I would love to be proved wrong though!


Me too! But, like I said, I need to hear both results with my own ears first.

We should be able to do some interesting comparisons at the Chesterfest. Any chance we could nail this particular dispute there? Perhaps Neal could come and prove 'his side'?

I'm all for learning!

Marco.

Tony Moore
11-07-2008, 11:12
Hi Marco,

I'll certainly bring along my DAC and CDPro then to ChesterFest.

It will be interesting to make some comparisons although the most obvious comparison, a like for like, SqueezeBox or CDPro2M is not possible now on my DAC as I'm using I2S dedicated to the SB3.

We could use the SqueezeBox s/pdif output of course into your DAC and compare that with my CDPro2m and your transport using the same method. I will have to wire up the s/pdif output again...at the moment I don't have it connected but thinking about it now I think I can easily make that mod in time for the "fest". It really _will_ be like for like as both the SqueezeBox and CDPro2M will be reclocked with Tent XO3 boards and use the same s/pdif output cct. (on the Tent XO3) So that's about as fair a test as can be created I think. :scratch:

Personally I don't think we'll hear any difference but I remain open minded! :)

DAC comparisons now...:eyebrows: Mine does not use any digital filters, or low pass output filter so it sounds quite raw and lively. I like it that way but others might find it harsh perhaps, depending on the amplification and speakers. It's the opposite of the veiled silky smooth sound of high oversampled bitstream! (you can perhaps tell I'm not a great fan of that!) :lolsign: Well, not quite true, I think I prefer that sound through headphones but it's just not as exciting through the speakers in my opinion. (On my system of course! It's all about synergy and personal taste after all!)

Cheers,
Tony

Marco
12-07-2008, 17:27
Hi Tony,

Sorry for my late reply!


I'll certainly bring along my DAC and CDPro then to ChesterFest.

It will be interesting to make some comparisons although the most obvious comparison, a like for like, SqueezeBox or CDPro2M is not possible now on my DAC as I'm using I2S dedicated to the SB3.

We could use the SqueezeBox s/pdif output of course into your DAC and compare that with my CDPro2m and your transport using the same method. I will have to wire up the s/pdif output again...at the moment I don't have it connected but thinking about it now I think I can easily make that mod in time for the "fest". It really _will_ be like for like as both the SqueezeBox and CDPro2M will be reclocked with Tent XO3 boards and use the same s/pdif output cct. (on the Tent XO3) So that's about as fair a test as can be created I think. :scratch:

Personally I don't think we'll hear any difference but I remain open minded!


Excellent. I'll look forward to it, and we'll see!


DAC comparisons now... Mine does not use any digital filters, or low pass output filter so it sounds quite raw and lively. I like it that way but others might find it harsh perhaps, depending on the amplification and speakers. It's the opposite of the veiled silky smooth sound of high oversampled bitstream! (you can perhaps tell I'm not a great fan of that!)


Me neither! Good old-fashioned multi-bit is where it's at, and I hate this current up-sampling nonsense with a passion. Your DAC sounds right up my street providing it doesn't totally trash poor recordings. That's what the Sony does so well: it's ultra-revealing yet it ekes out the music on any CD no matter who well or poorly recorded it is.

Sounds like it will be a fun day! I'm also planning to bring a little bit of Mana with me, mainly to set-up the 1210 properly (levelled accurately, etc) but It'll also be used to support the Sony. If you're going to do it I guess you may as well do it right :eyebrows:

Marco.

alb
13-07-2008, 08:58
I'm also planning to bring a little bit of Mana with me

Eeek, i'd better bring a spirit level and some blocks of wood for my table then.:scratch:

Seriously though, there should be ample time for these comparisons to take place, depending on what the others bring with them. Perhaps we could have a Mana support versus Caldy Valley table listening test.
Chesterfest looks to be shaping up nicely. We now have around 20 people interested.
A bit closer to the day i'll ask for confirmation of numbers and a rough idea of the equipment thats likely to be there. It's always good to have a plan even if we don't need it.

Marco
13-07-2008, 09:27
Hi Al,

It's just to get the 1210 properly levelled. T/Ts sound like pants if they aren't level.

Just as a practical thought, do you know (or can you find out) how many wall sockets there are in the room? Hopefully there's a few scattered around the place, so if possible we're not all crammed into the one area.

It sounds good that we'll have time to do some playing with bits and pieces. That's one thing that was missing for me at Owston, unless you had time to stay over on the Sunday.

Can you list the names, for reference, you've got so far of people who are definitely coming? Or PM it to me if you wish.

Marco.

Complin
13-07-2008, 14:42
I'm looking to use my i2s dac with my computer based FLAC files.
Does anyone know of a PC sound or interface card that has an i2s output?

I have come across a US company that sells interface boxes but they are very expensive . http://www.empiricalaudio.com/

Also anyone tried a software based sample rate converter. There is one called secret rabbit code (I jest not) that is supported on mac, win and linux?
http://www.mega-nerd.com/SRC/

One of the best forums for computer based audio is http://www.hydrogenaudio.org/forums/index.php

lurcher
13-07-2008, 15:34
Just a small comment about what Rob said:

"The software then averages the data omitting any data that isn't original (error corrected data for example)"

The error corrected data isn't a problem, its the data that the error correction can't fix, that then gets interpolated thats the problem. The error correction code on red book works by adding redundancy to the data, such that a small number of bits per frame (can't remember exact details, Neal?) can be perfectly corrected.

If I make it to Chester Tony, we could try hooking up your CDPRO i2s to the front of my cpld, that would make for a interesting comparison of the damage that spdif may do. If I bring the laptop we can remap the CPLD inputs. Let me know nearer the event, and I will make up a level shifter from 5v to 3.3v.

Complin: If you want USB to i2s then the chap that makes the DDDAC has a board that does that, otherwise you would need a spdif input I guess. Its a shame a external spec for i2s never got produced, it would make a cracking interconnect. And there is the perfect cable and interface hardware now in the form of HDMI cable, and LVDT interface chips.

Mr. C
13-07-2008, 16:08
Tony,

I realise a lot of DIY guys use I2S as a data transfer medium (we are just putting finishing touching to a new method) however a lot digital units still use and will continue to use SPDIF, an intermediate 'sticking patch' could well be the Wolfson WM8804/5 reciever chips that start attenuating jitter from 100hz as opposed to 10khz also supports AES 3 fortmats too
jitter is claimed 50PS, may help out a few guys stuck with this format form a while.
Tony (other one!)

Complin
13-07-2008, 19:18
Complin: If you want USB to i2s then the chap that makes the DDDAC has a board that does that, otherwise you would need a spdif input I guess. Its a shame a external spec for i2s never got produced, it would make a cracking interconnect. And there is the perfect cable and interface hardware now in the form of HDMI cable, and LVDT interface chips.

Yes I know this is possible but defeats the whole object. USB is quite limited for Audio, even the new standard thats coming along. Lots of the cards use I2S internally, its just a case of either modifying one or getting a manufacturer to build one. There are now several DAC's out this with I2S input. Probably we might get one of the manufacturers that supply the Pro market to do something?
I know of the DDDAC has a board sand understood that you might be able to take an I2S tap off one of them without going through USB? One of the gaming manufacurers (Razer i think) has one with 4 internal I2S outputs.

Complin
13-07-2008, 19:26
Tony,

I realise a lot of DIY guys use I2S as a data transfer medium (we are just putting finishing touching to a new method) however a lot digital units still use and will continue to use SPDIF, an intermediate 'sticking patch' could well be the Wolfson WM8804/5 reciever chips that start attenuating jitter from 100hz as opposed to 10khz also supports AES 3 fortmats too
jitter is claimed 50PS, may help out a few guys stuck with this format form a while.
Tony (other one!)

If im interpreting you correctly (we are just putting finishing touching to a new method) i dont think we need any more? Unless you can convince me otherwise? We already have
SPDIF
USB 3 due soon?
I2S
Firewire
And several propietary.......

lurcher
13-07-2008, 20:01
The problem with i2s is that while it seems to be a standard, its not there yet. Take this article that was linked to earlier. http://www.empiricalaudio.com/, that describes i2s as containing four signals, but the last time I looked i2s was three signals. http://www.nxp.com/acrobat_download/various/I2SBUS.pdf.

But you still have the descision bases jitter problems as the interconnect length increases.

I haven't read too much on the subject, but I can't see why USB should be that much of a problem, as long as the interface is intelegent, buffers data, and provides its own clock to stream out of its fifo. If I can connect a external disk driver via USB, then there is no inherent reason why it shouldn't work fine for audio.

Complin
13-07-2008, 20:45
The problem with i2s is that while it seems to be a standard, its not there yet. Take this article that was linked to earlier. http://www.empiricalaudio.com/, that describes i2s as containing four signals, but the last time I looked i2s was three signals. http://www.nxp.com/acrobat_download/various/I2SBUS.pdf.

But you still have the descision bases jitter problems as the interconnect length increases.

I haven't read too much on the subject, but I can't see why USB should be that much of a problem, as long as the interface is intelegent, buffers data, and provides its own clock to stream out of its fifo. If I can connect a external disk driver via USB, then there is no inherent reason why it shouldn't work fine for audio.

The I2S or Inter-IC Sound Standard was developed by Philips to allow audio data exchange between converters, filters and digital input/output interfaces. The serial interface is a three-wire bus that contains a line for two timemultiplexed data channels (Data), a word select line (L/R clock), and a clock line (Bit Clock). The standard also dictates that the actual audio data be delayed by one Bit Clock period from the L/R clock.

SDATA - serial data
SCLK - serial clock - usually 64fs
L/RCLK - delineates left and right data to demux them.

Most I2S interfaces defined by companies, add a fourth signal:

MCLK - Master clock, can be 256fs or 128 fs

These signals are essentially the interface to most modern D/A chips.

The first I believe to try to standardize I2S was Audio Alchemy, who offered both a transport and DAC with the interface. Later, the follow-on company Perpetual Technologies also put the interface on their P-1A and P-3A. They used the mini-DIN, which is a really unreliable connector.

The I2S Audio Interface provides a bidirectional, synchronous, serial interface to off-chip audio devices.

This is the protocol used inside CD players to connect the drive and the DAC.

It is a true computer protocol:

bidirectional: the devices can communicate with each other

signal (audio) and timing are send as data.

Compared with S/PDIF this protocol has the advantage of sending both the timing information and the signal as bits. This makes the receiver insensitive to input jitter.

tfarney
13-07-2008, 21:01
Marco, the only way you can do an apples to apples comparison would be with an external DAC, using the same DAC for playback from the computer and the CD transport. To help your old school point of view (to which I can relate) think of it this way -- the most elegant, most stable mechanical designs are often the simplest. Fewer moving parts means greater reliability and stability. Using a computer as source, you don't play CDs from the CD drive. You don't even play them from the hard drive. You play them from RAM (after once again error-checking to ensure a bit-perfect data match between hard drive and RAM. No moving parts. It may not have that heavy hardware look that makes us feel all warm and secure, but it doesn't get any more elegant or stable than no moving parts.

By the way, I'm not a believer in the superiority of one ripping program over another for the same reasons. It's all data, no audio. If the zeros and ones on the hard drive match the zeros and ones on the CD, the file is correct. It doesn't matter a lick if you did it with iTunes or some other program, if the error correction is turned on, the zeros and ones will match. I've ripped hundreds of CDs and every time I heard an error in a file, I found exactly the same error on the original CD. It's really very simple: There is no distortion, no coloration, no "quality" to be judged objectively or subjectively. Until it hits the DAC, it is data, and it is either correct or not, and data errors are not subtle, you will not miss them. Timing errors, jitter, are another subject, another thread.

Tim

Marco
13-07-2008, 21:47
Hi Tim,


Marco, the only way you can do an apples to apples comparison would be with an external DAC, using the same DAC for playback from the computer and the CD transport.


This is something I'll hopefully get a chance to do at a local audio meeting on 23rd August. The event will be reported and featured in detail on the forum, so you can look out for that when the time comes :)

Like I said, I'm in no way disputing what you're saying, but for me the proof of the pudding is *always* in the listening. I do not judge hi-fi and form opinions any other way, no matter what is said on paper. Automatically accepting things simply because technology 'says so' is not my style.


To help your old school point of view (to which I can relate) think of it this way -- the most elegant, most stable mechanical designs are often the simplest. Fewer moving parts means greater reliability and stability. Using a computer as source, you don't play CDs from the CD drive. You don't even play them from the hard drive. You play them from RAM (after once again error-checking to ensure a bit-perfect data match between hard drive and RAM. No moving parts. It may not have that heavy hardware look that makes us feel all warm and secure, but it doesn't get any more elegant or stable than no moving parts.


That's an excellent explanation, and one I can relate to. The whole ethos behind my hi-fi system is maximum fidelity to the source signal, keeping signal paths as short as possible, and maintaining the integrity of the signal - that's why for example I have a hard-wired mains set-up (no mains 'strips' plugs, fuses, etc), so I 'dig' you there :smoking:


If the zeros and ones on the hard drive match the zeros and ones on the CD, the file is correct. It doesn't matter a lick if you did it with iTunes or some other program, if the error correction is turned on, the zeros and ones will match. I've ripped hundreds of CDs and every time I heard an error in a file, I found exactly the same error on the original CD. It's really very simple: There is no distortion, no coloration, no "quality" to be judged objectively or subjectively. Until it hits the DAC, it is data, and it is either correct or not, and data errors are not subtle, you will not miss them. Timing errors, jitter, are another subject, another thread.


Again, I'm not in a position to dispute this as I haven't tried it, but isn't what you're saying also saying in the same way that all CD transports should be identical when playing CDs? It's just zeros and ones - just data until it hits the DAC? Or are the rules different when ripping?

In my experience as far as playing CDs are concerned, and as you know because I've written about it on the forum at length, that is most certainly not the case. Transport quality very much matters.

Forgive me if I've misunderstood you on that part.

Marco.

lurcher
13-07-2008, 22:10
The I2S or Inter-IC Sound Standard was developed by Philips to allow audio data exchange between converters, filters and digital input/output interfaces. The serial interface is a three-wire bus that contains a line for two timemultiplexed data channels (Data), a word select line (L/R clock), and a clock line (Bit Clock). The standard also dictates that the actual audio data be delayed by one Bit Clock period from the L/R clock.

SDATA - serial data
SCLK - serial clock - usually 64fs
L/RCLK - delineates left and right data to demux them.

Yes, agreed.


Most I2S interfaces defined by companies, add a fourth signal:

MCLK - Master clock, can be 256fs or 128 fs

Yes, and that stops its being i2s, I agree most recievers generate that clock, but its not part of i2s. If you want to use that, good, but don't call it i2s.


These signals are essentially the interface to most modern D/A chips.


Well, no, only some. There are many single channel DACs out there.


The I2S Audio Interface provides a bidirectional, synchronous, serial interface to off-chip audio devices.

Its not bi-directionally, it can run as a slave or master WRT the clocks, but its not defined as a tri-state signal.


It is a true computer protocol:

Well, not sure what that means, but its often 5v TTLCMOS, but doesn't need to be.


bidirectional: the devices can communicate with each other

Well, only in the master/slave way, the interface doesn't define any metadata between devices.


signal (audio) and timing are send as data.

instead of sending it as what?


Compared with S/PDIF this protocol has the advantage of sending both the timing information and the signal as bits. This makes the receiver insensitive to input jitter.


Yes, agreed, but I would have said "This makes the receiver MORE insensitive to input jitter". The moment you take the signal over more than a few inches, jiter is back. LVDT can help with that though.

tfarney
14-07-2008, 01:32
Like I said, I'm in no way disputing what you're saying, but for me the proof of the pudding is *always* in the listening. I do not judge hi-fi and form opinions any other way, no matter what is said on paper. Automatically accepting things simply because technology 'says so' is not my style.

I like your style. I agree completely, even though I suspect our ears sometimes reach very different conclusions. This is a little different, though. You can't "listen" to digital data. There is nothing to listen to until digital to analog conversion and while the stability of the drive can make a big difference in the accuracy of reading the data when "playing" a cd, the methodology used in ripping cds takes the playing of the cd completely out of the equation.


That's an excellent explanation, and one I can relate to. The whole ethos behind my hi-fi system is maximum fidelity to the source signal, keeping signal paths as short as possible, and maintaining the integrity of the signal - that's why for example I have a hard-wired mains set-up (no mains 'strips' plugs, fuses, etc), so I 'dig' you there :smoking

I like your ethos, too. Keep an eye on digital technology. It is marching forward pretty quickly, and all-digital amps, like the Lingdorf, do for pre-amplification and amplification what ripping CDs to hard drive does for transports -- it makes short signal paths, audiophile caps, resistors, wire, etc. completely irrelevant by keeping all the processing, the entire path in the digital realm until just before it puts voltage on the speaker terminals. There is no need to worry about short signal paths or clean signal paths, because there is no signal path. It's like taking the data straight off of the cd and putting it on your speaker terminals as voltage. It is a radical leap forward. If we could only reconcile our desire for resolution with our dislike for a bit too much of it, and warm it up a bit, it would be a revolution.


Again, I'm not in a position to dispute this as I haven't tried it, but isn't what you're saying also saying in the same way that all CD transports should be identical when playing CDs? It's just zeros and ones - just data until it hits the DAC? Or are the rules different when ripping?

No, because cd players are trying to "play" cds in real time, directly off of the cd. There is no RAM buffer, no error correction checking verifying that the zeros and ones at the source (hard drive) match the zeros and ones in RAM.


In my experience as far as playing CDs are concerned, and as you know because I've written about it on the forum at length, that is most certainly not the case. Transport quality very much matters.

Transport quality absolutely matters if the transport is engaged in the playback of the music. In the scenario we're talking about, it is not.

Tim

Marco
14-07-2008, 07:18
Tim,

Excellent post, I understand and completely agree.


I like your style. I agree completely, even though I suspect our ears sometimes reach very different conclusions. This is a little different, though. You can't "listen" to digital data. There is nothing to listen to until digital to analog conversion and while the stability of the drive can make a big difference in the accuracy of reading the data when "playing" a cd, the methodology used in ripping cds takes the playing of the cd completely out of the equation.


Yep. What I was getting at with listening is the end result with music, not at the stage you're referring to above. 'Music signals' (what we hear after the conversion process) as you know are different from the raw data described above, and is one of the reasons why in hi-fi, electrical measurements via test apparatus mean very little in a real sense. The end 'music signal' (what the ear detects with music) is all that really matters.

I'm just curious if a high quality CD transport will provide a better source signal for ripping than a computer transport using the same DAC. I suspect though what you say will be right. All will be revealed in due course! :)

Marco.

NRG
14-07-2008, 08:20
I think there are two conversations going on here.

Howards initial post was about playing into a Mac/PC. The best way to do this is DAE. Period.

The other conversation seems to be playing a CD vs listening to the same CD but stored on HDD which is a whole different discussion.


No, because cd players are trying to "play" cds in real time, directly off of the cd. There is no RAM buffer, no error correction checking verifying that the zeros and ones at the source (hard drive) match the zeros

No not true. There is a RAM buffer the difference comes in the quality of the transport and if the manufacture bothered to implement C1 and C2 level error detection. The data read from a CD is not one's and zeros as such, the waveform, as I said earlier, is sinusoidal and the quality or 'eye pattern' of that signal is important to the resulting quality of the data stream and thus audio quality. This is why playing from an HDD is so much better, it removes one very large variable from the digital audio playback chain.

Marco has noticed variations in CD transports and he is correct, they are different and sound different but an HDD eliminates this variability leaving really just the DAC as the key arbiter to ultimate sound quality.

I had an interesting conversation over on PFM a few months back in a similar vein and we agreed that early CD transports from Philips/Sony etc showcased the new 'perfect music forever' technology by correctly engineering the transports and utilising C1 and C2.

Later CD mechs seem to be a bit of a lottery with some implementing no error correction and others doing it correctly. I did a bit more research on computer based CD mechs that some manufacturers now choose to use and there is variability on what features and functions can be supported like C2 error correction. It seems to come down to what features the manufacture enables in firmware, some support DAE with and playback with C2, many others don't.

I can't make Chesterfest, would love to come but I'm on hols and significant others would be rather p1zzed off if I attended!

Marco
14-07-2008, 08:43
Very interesting, Neal. Particularly this bit:


I had an interesting conversation over on PFM a few months back in a similar vein and we agreed that early CD transports from Philips/Sony etc showcased the new 'perfect music forever' technology by correctly engineering the transports and utilising C1 and C2.


Now I had not even heard of "C1 and C2" before now, yet from listening experience my ears clearly told me that the Sony CD transport I use is an order of magnitude better than most of what's made today and completely pooh-poohs the notion claimed by many objectivist 'measurement types' that transport quality does not matter, as it's all simply just ones and noughts. Like you say, engineering matters, as quite frankly it does in all areas of hi-fi. This is also probably why DVD ROMs don't cut it with music replay on CD unless you up-sample, which imposes its own (IMO detrimental) signature on the music.

Could you explain a little more what "C1 and C2" are exactly? In easy to understand layman's terms please ;)

Sorry you can't make it to the Chesterfest but I'm sure you'll be having plenty of fun on your hols. You'll hear about it all when you get back. Going anywhere nice?

Marco.

NRG
14-07-2008, 10:18
Ok I’ll try! It’s not easy…

C1 errors exist or are present on all disks to a certain degree so we have to live with them and correct them… they are small random bit errors. C2 errors are nastier and we don’t want any of them… they are larger burst errors.

All audio CD’s use Cross Interleaved Read-Solomon code (CIRC). It’s the fundamental encoding and error correction scheme used on CD. It consist of three levels, considered good enough for audio data but not good enough for computer data. Audio data that cannot be corrected via C2 correction can be interpolated or guessed. You can’t guess with computer data!

The three error correction levels are C1, C2 and interleaving of the data on the audio CD. IE: the CD is formatted in such away blocks of data are mixed up in a predefined manner to allow for reading of the disk if scratches / imperfections are present. Interleaving cannot correct for errors by itself it only allows you to recover sufficient data blocks for C1 and C2 to work.

C1 and C2 Error Correction Codes (ECC) are applied to the audio data during the mastering process of the CD IE: when interleaving the Audio Data prior to it being placed on the CD. They are used at different points of the de-interleaving process or playback of the Audio data, C1 first then C2.

Now our Audio CD mechanism manufacture may only wish to implement the basic C1 (he has to implement CIRC otherwise he couldn’t read the disk!) and ignore C2 or he can spend a little more money and implement it fully.

However, there is also the physical quality of the mech. to consider. A cheap mech. with poor servos and supply regulation will produce an ‘eye pattern’ of the disk that is not clean (the optics need to track the CD as accurately as possible), this means any error correction scheme has to work harder to correct errors and as the resulting digital stream has to be created from a sinusoidal output from the laser jitter becomes a potential issue. Maybe it’s why you can notice differences in transports…

With a PC based mech. when we perform DAE we are reading the data from the CD in the same way as when we play it except the data this time is directed over whatever computer interface the mech. has (IDE, SCSI etc) and not directed to a DAC. The de-interleaving and error correction schemes are still applicable.

The quality of the mech. is again important and again it really needs to support C2 error correction and have the feature enabled in firmware. The difference now is we have the ability via s/w on the computer to buffer the read data and also to re-read parts of the CD and perform offset reads to recover the audio track. Software can do this because it’s not constrained by playing the CD in real time. However, not all PC based mechs. are equal but the latest DVD multifunction drives seem to do a very good job. EAC is well know and seems to do an incredible job of recovering read errors given a compatible drive.

In theory, playing back the Audio CD from a dedicated player into a DAC compared to playing the same CD extracted to HDD via the same DAC will sound exactly the same…as long as the copy to HDD to bit correct and the dedicated player is capable of recovering in real time the same exact bit data.

I think I’ve rambled on to long!

Marco
14-07-2008, 10:28
Neal,

Thanks for taking the time and effort to write that - much appreciated :)

I get the gist of what you're saying (which is good enough) although quite a lot went over the top of my head!

This bit however is obviously pertinent to what I've been writing on audio forums for years, namely that transport quality matters:


However, there is also the physical quality of the mech. to consider. A cheap mech. with poor servos and supply regulation will produce an ‘eye pattern’ of the disk that is not clean (the optics need to track the CD as accurately as possible), this means any error correction scheme has to work harder to correct errors and as the resulting digital stream has to be created from a sinusoidal output from the laser jitter becomes a potential issue. Maybe it’s why you can notice differences in transports…


I like the explanation of "eye pattern". I think that's pretty much what's going on.

All interesting stuff, this. It's always nice when one's subjective assessments are reinforced by objective data.

Marco.

tfarney
14-07-2008, 10:36
Ok I’ll try! It’s not easy…

C1 errors exist or are present on all disks to a certain degree so we have to live with them and correct them… they are small random bit errors. C2 errors are nastier and we don’t want any of them… they are larger burst errors.

All audio CD’s use Cross Interleaved Read-Solomon code (CIRC). It’s the fundamental encoding and error correction scheme used on CD. It consist of three levels, considered good enough for audio data but not good enough for computer data. Audio data that cannot be corrected via C2 correction can be interpolated or guessed. You can’t guess with computer data!

The three error correction levels are C1, C2 and interleaving of the data on the audio CD. IE: the CD is formatted in such away blocks of data are mixed up in a predefined manner to allow for reading of the disk if scratches / imperfections are present. Interleaving cannot correct for errors by itself it only allows you to recover sufficient data blocks for C1 and C2 to work.

C1 and C2 Error Correction Codes (ECC) are applied to the audio data during the mastering process of the CD IE: when interleaving the Audio Data prior to it being placed on the CD. They are used at different points of the de-interleaving process or playback of the Audio data, C1 first then C2.

Now our Audio CD mechanism manufacture may only wish to implement the basic C1 (he has to implement CIRC otherwise he couldn’t read the disk!) and ignore C2 or he can spend a little more money and implement it fully.

However, there is also the physical quality of the mech. to consider. A cheap mech. with poor servos and supply regulation will produce an ‘eye pattern’ of the disk that is not clean (the optics need to track the CD as accurately as possible), this means any error correction scheme has to work harder to correct errors and as the resulting digital stream has to be created from a sinusoidal output from the laser jitter becomes a potential issue. Maybe it’s why you can notice differences in transports…

With a PC based mech. when we perform DAE we are reading the data from the CD in the same way as when we play it except the data this time is directed over whatever computer interface the mech. has (IDE, SCSI etc) and not directed to a DAC. The de-interleaving and error correction schemes are still applicable.

The quality of the mech. is again important and again it really needs to support C2 error correction and have the feature enabled in firmware. The difference now is we have the ability via s/w on the computer to buffer the read data and also to re-read parts of the CD and perform offset reads to recover the audio track. Software can do this because it’s not constrained by playing the CD in real time. However, not all PC based mechs. are equal but the latest DVD multifunction drives seem to do a very good job. EAC is well know and seems to do an incredible job of recovering read errors given a compatible drive.

In theory, playing back the Audio CD from a dedicated player into a DAC compared to playing the same CD extracted to HDD via the same DAC will sound exactly the same…as long as the copy to HDD to bit correct and the dedicated player is capable of recovering in real time the same exact bit data.

I think I’ve rambled on to long!

NRG, I can't claim to have completely understood all of that, but I got enough to get a bit of an education. Thanks!

Tim

Tony Moore
15-07-2008, 16:30
Yes, thanks for that Neal! A really good explanation.

A great pity that you can't come to ChesterFest. :doh: You would've been made very welcome! :cool:

A previous post (not from you Neal) mentioned Inter IC communication. I believe that is called IIC or I2C and is another 3 wire specification for communicating between chips such as microcontrollers, EEPROMS, ADCs, computer peripherals etc. That bus _is_ bi-directional.

I2S is not the same thing although similar in some ways. I2S uses TTL levels and is master/slave with one end permanently master (transmitter), I2C uses passive pullups, active pulldown so multiple transmitters can be on the same bus, it can swap masters is is much more sophisticated than the simple I2S, intended to carry data packets of varying content.

Cheers,
Tony