Since They will No Longer Make CD's

steveinaz

Since my recent acquisition of a squeezebox touch, I can say that I much prefer music from a hard drive (lossless *.flac), rather than an optical transport. Detail to the nth degree, a smoother overall presenation. Take it for what it's worth. I believe the real hero here is the hard drive--the Touch simply acts as a conduit to pass the digital to the DAC, but obviously does that extremely well.

I was skeptical to say the least, but after doing extensive A/B'ing against my CEC transport--and as much as I hate to admit it--the HDD/Touch combo resolves detail better, and is smoother.

BeefJerky

heiney9 wrote: »

I see, so on the one hand you state redbook playback has woefully inadequate error correction

It is inadequate in my opinion since optical media is quite prone to read errors due to scratches, dirt, fingerprints, etc. Data CD's have an additional layer of error correction, which makes them less prone to read errors.

which makes them inferior to a PC based system,

That alone doesn't make them inferior, though, a PC based system does have much more resilient error correction. However, I believe part of the advantage is also the convenience of not having to fumble with discs, as well as a convenient easy-to-search database. In addition, it is also very easy to setup a playlist with multiple artists/albums/songs, including very large uninterrupted playlists.

yet all the files sound the same whether it's a cd or a lossless PC generated file.

If you get a bit-for-bit copy, yes. That can be quite hard on a disc that isn't in good shape, but if you yours is in good shape it should be very easy.

So yes, a bit-for-bit copy is identical to the original CD, and will sound exactly the same.

I am done here Beef thinks that numbers don't lie and because the numbers are the same the file is the same, period.

Basic math doesn't lie, and that is all we are dealing with when comparing a lossless file to a CD. Do you think 2+2 equals something other than 4?

Just like amplifiers that have better numbers sound better than amplifiers with lesser numbers. Audio is not always about the raw data.

Except that the typical data given in regards to amplifiers and speakers aren't everything. The most common is of course a frequency response graph, but that is only a part of it. That graph certainly doesn't take into account timbre, or even how linearly it reproduces different levels of volume.

Anyway have fun, but I can't continue to try and decode his logic.

H9

Thanks, and I'm sure we will have fun.

tonyb wrote: »

Guess by all accounts, my brain and my ears are telling one big fib.

It happens to everybody. There's a reason that medical testing requires use of a control group with placebos. In that case, a person can begin to feel better for the simple reason that they they think they are being treated. It also applies to any kind of input stimuli, including your ears. Ever feel an itch that isn't due to external stimuli? Everyone has, that's your brain/nervous system lying to you as well.

Maybe we should just drop all this audio nonsense and go back to boomboxes........not!!

I never claimed we should, nor do I believe that. However, some of those old 80's giant-size boomboxes were kind of cool.

I haven't been this amused in awhile.

Glad you're having fun.

Beef, for someone who claims that audio isn't up there on his priority list and trying different gear not that big of a deal either, than thats pretty telling right there.

How so?

This is by no other means a subjective hobby, and you really can't experience it to the fullest by painting yourself into a corner of theory and numbers.

It's not all subjective, nor is it all objective. There are parts that are truly objective and can easily proven via mathematics. This includes the area dealing with lossless files. Or, will you be arguing whether or not 2+2=4 as well?

No offense ment my friend, for I myself was once stuck on theory and numbers. Good luck to you on your audio journey.

None taken. I enjoy audio, but have other more important things going on my life right now that preclude making it any sort of priority. However, I do enjoy visiting and posting on this board to get away from real life sometimes.

steveinaz wrote: »

When it comes to Redbook, error correction has 2 by-products; 1) The "error" gets corrected and you hear no change. 2) The error doesn't get corrected and it is audibly apparent (drop-out/skip, etc). Bottom line, there are no "subtle" by-products of error correction.

This is incorrect. All CD players that I know of will try to interpolate missing samples in order to avoid a drop-out or click. This will lead to a subtle change in that particular sample of the CD. If too many samples are missing, you will then get a drop-out or click. Note that this does not apply to ripping a CD on a PC, as it will just replace those missing samples with null bits rather than trying to interpolate.

steveinaz

Correct, but the interpolation "guess" would not result in a distortion product. I think where optical drives may fall short, is in the techniques for reading data from the disc, and (potential) imperfections in the dics pits. When you go hard drive, you are by-passing the need for lasers, sleds, servos, tracking and speed electronics, etc, etc. Simple is better, IMO.

Error correction is a pass/fail proposition, either it works--and you are unaware of it; or it doesn't, and you are certainly aware of it. Now, whether the error correction process induces some sort of extraneous noise, etc is another debate altogether.

heiney9

steveinaz wrote: »

When you go hard drive, you are by-passing the need for lasers, sleds, servos, tracking and speed electronics, etc, etc. Simple is better, IMO.

What do you think your computer uses to extract the initial info to a HD? A laser, mounted with a servo, that has to track a poycarbonate disc with the same pits in it via a sled.

I have discussed this before, in the archives, about cd error correction and it's either right or wrong, there is no gray area as Beef seems to think. He is wrong about that. I urge him to search the archives for factual links that I am not prepared to rehash yet again.

I agree with you Steve, except where you state you are eliminating lasers, sleds, servo's, tracking, speed etc. This all comes into account when you are ripping a disc, if it affects the outcome of the final data stream in the same way as a cdp does, I have no idea. But all the same things like jitter and all the other byproducts of extracting the digital info from the disc are the same regardless of whether it's a computer or cdp.

H9

BeefJerky

steveinaz wrote: »

Correct, but the interpolation "guess" would not result in a distortion product.

It wouldn't be likely to result in distortion in the typical sense. However, depending on how accurate the guess is, the end result could be a subtle, but audible change in the output. This could of course vary based on how many samples are being interpolated and how complex the waveform is.

I think where optical drives may fall short, is in the techniques for reading data from the disc, and (potential) imperfections in the dics pits. When you go hard drive, you are by-passing the need for lasers, sleds, servos, tracking and speed electronics, etc, etc. Simple is better, IMO.

I agree with this. Optical has advantages, but it also has some real disadvantages that are still yet to be overcome..

steveinaz

But Brock, once a CD is read--the data is CONFIRMED/RESOLVED fully and written as a 1 or 0. There's no more "interpretation" needed from a laser, or any need for the associated electronics. You're also not dealing with pit imperfections due to the above. Getting a "1" from a pit involves a lot more (processes and electronics) than getting a "1" from a hard drive surface. Think of an optic drive like a Toslink cable. With toslinlk, you've added a step that coaxial doesn't need; same with optical drives--you first have to pull the data correctly, then interpret it correctly.

Most of this is my theory, but I think the logic rings true. I have a lot more confidence in a hard drive reading data accurately, than I do a laser reading pits.

heiney9

steveinaz wrote: »

But Brock, once a CD is read--the data is CONFIRMED/RESOLVED fully and written as a 1 or 0. There's no more "interpretation" needed from a laser, or any need for the associated electronics. You're also not dealing with pit imperfections due to the above. Getting a "1" from a pit involves a lot more (processes and electronics) than getting a "1" from a hard drive surface.

Except I have files that have digital hash or dropouts after being ripped by something that is supposed to completely "resolve" any issues. Granted these are rare, but if it's simply written as a 1 or 0, how do these files aquire a distortion when it's not present on the original disc.

I borrow discs from the library and a particular Carlos Santana cd which is pretty scratched up plays fine on a cdp. When I go to rip it the entire disc sounds like someone has the FF set on the cdp. The FLAC file skip all over the place. How can this be if a cdp's error correction is inferior to a PC which is supposed to just extract the info as a 1 or 0? Don't kid yourself a PC uses error correction as well, it's built into the extraction software. So it's not as simple as being fully resolved.

In the end I suppose you and I are arguing semantics as I see/hear no downside to digital music servers. I have been immersed in it for over 3 years and am thrilled to death and can't tell a difference between it and a cd playing in a cdp.

In the end that's all that matters to me and knowing that I am using the proper software to ensure bit perfect copies when ripping.

H9

BeefJerky

heiney9 wrote: »

What do you think your computer uses to extract the initial info to a HD? A laser, mounted with a servo, that has to track a poycarbonate disc with the same pits in it via a sled.

Correct. However, a disc in good condition shouldn't have a problem with being extracted bit-for-bit.

I have discussed this before, in the archives, about cd error correction and it's either right or wrong, there is no gray area as Beef seems to think. He is wrong about that. I urge him to search the archives for factual links that I am not prepared to rehash yet again.

Correct, redbook CD error correction (or any error correction for that matter) is right or wrong. The problem with redbook CD error correction is that it is too easy to end up with a failure. Data CD's have a third layer of error correction that is more resilient to errors, and therefore a scratch or piece of dirt is less likely to cause a read failure. I simply believe that redbook audio CD's should have that additional layer of error correction as well. That is what I have been saying all along, and I'm still not sure where the confusion arises.

I agree with you Steve, except where you state you are eliminating lasers, sleds, servo's, tracking, speed etc. This all comes into account when you are ripping a disc, if it affects the outcome of the final data stream in the same way as a cdp does, I have no idea. But all the same things like jitter and all the other byproducts of extracting the digital info from the disc are the same regardless of whether it's a computer or cdp.

Jitter only applies after the data is decoded and is sent to the DAC. It does not apply when ripping a CD to a lossless file since timing is irrelevant at that point. It can become an issue at the point where your PC's audio player is sending the data to the sound card or external DAC. However, a proper PC audio setup shouldn't have any audible issues in terms of jitter.

Except I have files that have digital hash or dropouts after being ripped by something that is supposed to completely "resolve" any issues. Granted these are rare, but if it's simply written as a 1 or 0, how do these files aquire a distortion when it's not present on the original disc.

Then you are not actually getting a bit for bit copy. Whether it is a failure in your CD drive or software (or something else) I don't know. I know that some CD readers don't actually report C1 and C2 errors properly, so the software may never know that a read error has occurred.

I borrow discs from the library and a particular Carlos Santana cd which is pretty scratched up plays fine on a cdp. When I go to rip it the entire disc sounds like someone has the FF set on the cdp. The FLAC file skip all over the place. How can this be if a cdp's error correction is inferior to a PC which is supposed to just extract the info as a 1 or 0? Don't kid yourself a PC uses error correction as well, it's built into the extraction software. So it's not as simple as being fully resolved.

A CDP's error correction should be the same regardless of whether it is a PC or CDP, however, that isn't always the case. As mentioned above, some CD drives have issues with reporting error correction. I think the bigger difference may be in the CD mechanism. I wouldn't be surprised if the mechanism was vastly superior in a quality CDP versus a typical CD drive on a PC.

Finally, it may be a matter of the CDP interpolating some samples to cover up the error correction failures. When ripping a CD it won't interpolate, it will simply replace them with null samples.

In the end I suppose you and I are arguing semantics as I see/hear no downside to digital music servers. I have been immersed in it for over 3 years and am thrilled to death and can't tell a difference between it and a cd playing in a cdp.

I'm a fan of digital music servers as well.

heiney9

BeefJerky wrote: »

Jitter only applies after the data is decoded and is sent to the DAC.

That is highly, highly debateable. I won't say you are dead wrong as there are valid, supported evidence on both sides.

H9

BeefJerky

heiney9 wrote: »

That is highly, highly debateable. I won't say you are dead wrong as there are valid, supported evidence on both sides.

H9

I honestly don't see how. Jitter should only be a problem when dealing with timing-dependent devices/processes. Ripping a CD isn't a timing dependent process. The CD drive could sit for 5 minutes trying to read a sector and the software would simply wait; there would not be any affect on the written data.

However, once the sound card and DAC come into play, it is a completely different matter. Data is expected to flow at a steady rate to the DAC, and if that is changed or interrupted, that is where the problem of jitter arises.

Maybe someone can give a good explanation as to why jitter would affect a CD rip, but as of now I don't understand how.

heiney9

Sounds to me like there are all sorts of variables in PC based audio servers and what you expound upon as fact is not fact when dealing in real world situations vs. a theoretical model of how things should work, but don't always because of said variables.

Just because mathematics states it should work doesn't mean it will in practice if too many variables are present and those variable are manipulated. You seem to have an excuse for everything that happens outside of the facts you state as absolute fact.

I'm still trying to resolve this statement

A CDP's error correction should be the same regardless of whether it is a PC or CDP

All along you have been saying a cdp's error correction is inferior to a PC and now you are saying they should be the same?


H9

heiney9

BeefJerky wrote: »

I honestly don't see how. Jitter should only be a problem when dealing with timing-dependent devices/processes. Ripping a CD isn't a timing dependent process. The CD drive could sit for 5 minutes trying to read a sector and the software would simply wait; there would not be any affect on the written data.

However, once the sound card and DAC come into play, it is a completely different matter. Data is expected to flow at a steady rate to the DAC, and if that is changed or interrupted, that is where the problem of jitter arises.

Maybe someone can give a good explanation as to why jitter would affect a CD rip, but as of now I don't understand how.

I have discussed this subkect soooo many times. If you'd really like to know perhaps search my screename and jitter and see what comes up.

H9

steveinaz

My ears tell me that a transport/dac combo I've owned for over 7 years, and know intimately; Doesn't quite have the resolving power nor overall smooth character that hard drive stored music has. I'll leave the rest to the professors. It's my "suspicion" that eliminating unnecessary electronic stages may be playing a role in a process I can't otherwise explain. Since that IS in fact the only other variable that exist. (Cue Spock).

It should be assumed that all of this is dependant upon accurate ripping software/techniques, and that the source material was well engineered--that is a given at this level of audio.

SCompRacer

Linn of audio and recording studio fame claims read offset error of drives can introduce jitter in the ripping process. They suggest making sure the hardware is up to the task.

BeefJerky

heiney9 wrote: »

Sounds to me like there are all sorts of variables in PC based audio servers and what you expound upon as fact is not fact when dealing in real world situations vs. a theoretical model of how things should work, but don't always because of said variables.

Perhaps you should read my posts more closely. I just looked back through my posts, and there have only been a couple of things that I stated were fact:
1) A losslessly compressed file (FLAC, Apple Lossless, APE, etc) holds the same audio data as an uncompressed WAV/AIFF fille, and will sound exactly the same.
2) A lossless file holds the same audio data as a bit-for-bit copy of a CD, and they will sound exactly the same.

I stand by these two statements.

Just because mathematics states it should work doesn't mean it will in practice if too many variables are present and those variable are manipulated.

Except that when dealing a lossless files, there aren't a lot of variables or manipulations of said variables.

You seem to have an excuse for everything that happens outside of the facts you state as absolute fact.

You seem to think that I've stated more as fact than I really have. Please go back through my posts just like I did, and you will clearly see that I only stated two things as facts.

I'm still trying to resolve this statement
"A CDP's error correction should be the same regardless of whether it is a PC or CDP"

What is to resolve? Error correction algorithms are very straightforward. I don't know of any CDP or PC CD drive that has failed to implement them properly. The closest I can come is a few model's of PC CD drives that don't report the errors to ripping software properly.

All along you have been saying a cdp's error correction is inferior to a PC and now you are saying they should be the same?

I never stated that a CDP's error correction is inferior to a PC CD drives error correction. I have, however, stated that the error correction is vastly superior in a hard drive or SSD when compared to a CD drive (whether CDP or PC drive). I stand by that.

I have discussed this subkect soooo many times. If you'd really like to know perhaps search my screename and jitter and see what comes up.

I will look through that later today. However, I will say that since the origin of jitter comes from small timing variations affecting timing-dependent devices/processes, jitter should not affect a non-timing-dependent process such as CD ripping.

SCompRacer wrote:

Linn of audio and recording studio fame claims read offset error of drives can introduce jitter in the ripping process. They suggest making sure the hardware is up to the task.

This is true, but is not really jitter in the way the term is commonly used around here. However, as far as I know, it is not as pertinent as it was back in the early days of CD ripping. Modern drives are more likely to have a consistent read offset, and therefore they can be corrected. In addition, a lot of software is able to figure this out automatically via an audio CD and a database. Feel free to correct me if I'm wrong on this though, since I'm a bit foggy in this area.

cnh

Some interesting things above, but the topic is being beaten to death at this point.

Have fun with the 'tech squawk'!


cnh

steveinaz

For sure, less yacking and more listening.

SCompRacer

It sure is interesting......

Beef, here is the Linn docs page I referred to. I've owned and demo'd Linn gear, Linn studios brought me, or all of us, The Blue Nile so I'm open to their take on the jitter thing.:cheesygrin:

http://docs.linn.co.uk/wiki/index.php/CD_Ripping_Terminology

+ 1 to listening Steve! Good listening! Great listening!

Face

steveinaz wrote: »

My ears tell me that a transport/dac combo I've owned for over 7 years, and know intimately; Doesn't quite have the resolving power nor overall smooth character that hard drive stored music has.

Then there's something amiss in your rig.

steveinaz

Apparently. My CEC was only $600, so it's not exactly "state-of-the-art." My point exactly--cable, DAC, passive, amp, speakers, connection method all the same, the only variables? The transport and source (CD or HD data):

CD Disc-->CEC-->DAC
HD data-->Touch-->DAC

BeefJerky

SCompRacer wrote: »

It sure is interesting......

Beef, here is the Linn docs page I referred to. I've owned and demo'd Linn gear, Linn studios brought me, or all of us, The Blue Nile so I'm open to their take on the jitter thing.:cheesygrin:

http://docs.linn.co.uk/wiki/index.php/CD_Ripping_Terminology

+ 1 to listening Steve! Good listening! Great listening!

I actually ended up searching for and finding that page via a Google search just after my last post. Thank you for posting it, though!

I will admit that I forgot about EFM jitter, however, that doesn't really apply to the PC vs CDP debate since it is brought on by flaws in the CD itself. Therefore, this type of jitter will show up regardless of what type of player or drive the CD is put into. Also note that minor EFM jitter may be fixed by the C1 and/or C2 error correction. If it can't be corrected, you will hear a dropout, or the error will be part of the ripped file. Again, this is not dependent on whether the disc is in a CDP or PC CD drive.

They have a good, straightforward explanation of sampling jitter, which is what one is typically referring to when using the word jitter by itself. It also serves to strengthen my statements. This type of jitter is only relevant when the data reaches the sound card or DAC, as those are timing-dependent devices. Up until that point, it is just a stream of numbers and therefore has no jitter.

Serendipity

If this is the case, then I would think your rig is not set up properly.

SCompRacer

My take on the Linn doc is that read offset errors can lead to jitter. "Some ripping applications refer to this process [performing a realignment] as 'Jitter Rejection'." It leads me to believe it can happen and is not the absolute 'has no jitter' that you claim.

EDIT: Just to summarize, they must refer to a timing error in the ripping process, thus the term jitter applies.

heiney9

SCompRacer wrote: »

My take on the Linn doc is that read offset errors can lead to jitter. "Some ripping applications refer to this process [performing a realignment] as 'Jitter Rejection'." It leads me to believe it can happen and is not the absolute 'has no jitter' that you claim.

I concur and have posted evidence in the past. It's affect on the final product and human detectability is where the debate is, not whether it exists. Jitter exists beyond just taking place at the sound card/dac. Do some more research Beefjerky, rather than make assumptions based on a superficial read. I do apologize for copping out in pointing you to evidence to the contrary but this has been debated so many times I honestly don't have the time or energy to bring all this up again. Info is out there and you need to spend more than a few hours reading some of the superficial stuff before you start stating your hypothosis is supported.

H9

BeefJerky

SCompRacer wrote: »

My take on the Linn doc is that read offset errors can lead to jitter. "Some ripping applications refer to this process [performing a realignment] as 'Jitter Rejection'." It leads me to believe it can happen and is not the absolute 'has no jitter' that you claim.

This isn't as relevant in modern drives. Pretty much any CD/DVD/Blu-ray drive you buy today (or in the last 10 years) will be "accurate stream" capable. This means that it has a consistent and predicable read offset. This also means that it can be 100% compensated for, which means there is not a read offset error in the ripped file.

However, this was not the case in earlier times, and that is why I had to buy an expensive Plextor drive to get a proper rip back then. Nowadays, even my lousy laptop DVD drive can do a proper accurate stream rip.

BeefJerky

heiney9 wrote: »

I concur and have posted evidence in the past. It's affect on the final product and human detectability is where the debate is, not whether it exists. Jitter exists beyond just taking place at the sound card/dac. Do some more research Beefjerky, rather than make assumptions based on a superficial read. I do apologize for copping out in pointing you to evidence to the contrary but this has been debated so many times I honestly don't have the time or energy to bring all this up again. Info is out there and you need to spend more than a few hours reading some of the superficial stuff before you start stating your hypothosis is supported.

H9

Please note that I have gone further and given more detail on the different types of jitter in post #113. Just like most people, when I use the term "jitter" by itself, I am referring to sampling jitter. As the Linn document confirms, that kind of jitter is only present at the sound card/DAC, and not prior.

Also note my clarification regarding the read jitter in my post just above this one. It is simply not relevant nowadays with nearly drive being accurate stream capable.

SCompRacer

I remember when SCSI was where it was at when ripping a few years back. Still have the Plextor SCSI combo in the my old overclocked, water cooled, dual CPU SCSI PC in the basement. 10K Cheetahs in RAID 0. Expensive, now SATA whups up on it.

BeefJerky

SCompRacer wrote: »

I remember when SCSI was where it was at when ripping a few years back. Still have the Plextor SCSI combo in the my old overclocked, water cooled, dual CPU SCSI PC in the basement. 10K Cheetahs in RAID 0. Expensive, now SATA whups up on it.

Oh yeah, I remember when SCSI was where it was at. I had a SCSI Ultraplex 40x and a SCSI Plextor CD writer. These were hooked up to a rack mounted computer with 3x 74GB Atlas 10KIII drives in a (hardware) RAID5 array. That thing was screaming fast back in the day. However, the SATA SSD in my laptop now is freaking blows that setup out of the water.

I still have a few SCSI things around. I have an SGI Octane with a 15krpm Fujitsu drive and external Plextor 40x drive. I also have a Sun Ultra 60 with a 15k Fujitsu drive and an external Plextor 40x drive. I don't use them much, partially because they are so loud when running. However, with winter coming, I may run the Octane as a convenient space heater. :cheesygrin:

heiney9

BeefJerky wrote: »

Also note my clarification regarding the read jitter in my post just above this one. It is simply not relevant nowadays with nearly drive being accurate stream capable.

Simply not true, but ok if you say so. You obviously haven't done a lot of research.

I will say it one more time, then I'm done.

The debate about jitter (any jitter, not just what Beef seems to be selectively talking about) is not whether it manifests itself but how it affects the final outcome and whether or not we can hear all the various types.

That said.................after work I will be enjoyng my rig.

H9

headrott

BeefJerky, you need to think of the digital signal as more than "a stream of numbers". Those numbers are still made from electrons passing through wires, capacitors, resistors, transistors, etc. There is still an effect on those electrons by those components. The 1's and 0's are therefore effected by those components. So, when the 1's and 0's end up in a digial "bit for bit" file, those 1's and 0's are in theory an unaffected 1 or 0 but that is assuming a true perfect transfer of those electrons. That is, those electrons are not affected by any component and are "perfectly" transferred from one source to another. There is no "perfect" transfer of electrons in a computer system or any electronic compenent(s). Also, those electrons still have to travel through space and time and are affected by that travel. Even though there is a "correction" for this, it is again not a perfect correction. If you believe there is a perfect transfer in an analog or digital realm, perhaps you don't understand what you are saying as well as you suggest. As I have stated before, my ears and brain let me hear that there is no perfect transfer.

Again, what do your ears and brain hear?

Greg