Seems like a not so smart bet to me. This will cost you if anyone takes you up on it 😎
Jan
I’d love to see directivity plots at LF with varying placement and using the provided adjustment settings.
George
Could you also note the -3 and -6dB off axis freqs? Some mfr (JBL?) use 6dB points for some reason. But -3dB is quit noticable and more in line with electronic cut-off points.
THx-RNMarsh
THx-RNMarsh
It´s not so much about the BER performance of the players but the condition of the CD. Although people even danced on the surface of CDs at the first presentations it is clearly better to handle a CD like the "holy grail" .
If the condition is good, the player (without any additional external confounder like vibrations) should be able to retrieve the content with error rates at the theoretical limits. Occasional random errors could slip through though.....
That was also basically the result of our tests with readout and error detection.
That conclusion would be wrong. I did not comment earlier as i wrote (maybe already within this thread?) that the physical data representation on a CD containing digital data is exactly the same but that the additional detection and correction capabilities takes place one level above.
Which means - anatech did mention it already - that a CD-R could contain a digital audio track which was encoded (and should be according to the standards if markes as digital audio track) in exactly the same way as it would be on a CDDA. This track might have, due to some defects in the information layer or the surfache, some interpolations.
Exactly the same audio samples can be encoded as digital data (for example a .wav file) on the same CD-R. Now it will be encoded in a different way, which means it gets additional scrambling, an additional reed solomon product code encoding, additional interleaving, so that in the end nearly every byte written on the CD-R will have a different meaning.
But the physical structure, means pits, lands, T3 - T11 requirement, frame size and so on, will still be same as on a CD DA.
But now, given the same condition of the information layer and surface, this file will contain most probably no errors.
Postscript: I am sure we linked it quite a lot already earlier, but ECMA provides the standard for CD-R as a free document:
http://www.ecma-international.org/publications/standards/Ecma-130.htm
Last edited:
Now this is gibberish, sorry information theory at work here, you can't get more error correction without sacrificing overhead. A .wav file is just data it has no embedded error correction at all. It is not encoded in a different way, what does CDROM uses the same error correction as Redbook mean? The CDROM Yellow book is concerned with file systems, single vs. multi-session, etc.
This idea that CDROM's and audio CD's have totally different error correction schemes is one of the biggest folklore scams going it feeds directly into the audio snake oil business.
EDIT - Did you even look at your link? The CIRC spec is identical to the Redbook one Jan posted.
Last edited:
The additional redundance on a CD-R is exactly the reason why its capacity is lower than you should expect if know the CDDA....
I said nothing different. 😉
But nevertheless the .wav file gets a different encoding (because it is stored as _digital_ _data_ instead of _digital_ audio_ ; i.e. a different mode is marked and invoked )
That you haven´t noticed that i usually know my stuff is really a pity. 😎
May i politely suggest that you just read the linked ECMA 130?
Hi Scott,
As far as I know, Audio CDs are encrypted differently than data CDs are. There should be more overhead room taken from a data CD. This is the reason that an audio CD player cannot "play" a data CD.
Don't forget, the CD was set down as a standard at the time when they were also pushing the maximum length of play as well. For a computer application, data is far more important than on an audio CD where it may cause the odd chirp or mute. It's only tunes, man. 🙂
-Chris
As far as I know, Audio CDs are encrypted differently than data CDs are. There should be more overhead room taken from a data CD. This is the reason that an audio CD player cannot "play" a data CD.
Don't forget, the CD was set down as a standard at the time when they were also pushing the maximum length of play as well. For a computer application, data is far more important than on an audio CD where it may cause the odd chirp or mute. It's only tunes, man. 🙂
-Chris
My apologies this has gone far astray from just how many interpolations are normal in a CD. We still don't have a definitive answer.
Last edited:
Encoding for audio and data are different. The basics of the data encoding are covered in the Yellow Book (unfortunately not freely available). The main differences from audio encoding are a third layer of Reed Solomon error correction and a slightly different scrambling method.
Thanks Jan. Enjoy the work!
Some good history info
http://www.turing-machines.com/pdf/hero.pdf
George
Some good history info
http://www.turing-machines.com/pdf/hero.pdf
George
It was more the cable masking/correcting any mismatch that I was questioning, I have done may sims of the SPDIF interface, its pretty rugged, and minor impedance changes don,t alter the bit pattern in any way, they just alter the square wave a tiny bit. All easily solved with the correct termination at the receiver end.
Also I was interested in the claim that so many CD players have poorly designed SPDIF outputs... The transmitting device will probably have quite a decent current drive as the designers will need to cater for a few different cable lengths, the first impedance the signal will see is the traces on the PCB layout. These and the PCB will probably not be a controlled impedance design (very few are at this level and don't need to be). If the layout is a 4 layer design i would suspect from common layout practices that the initial line will be approx 70-85R depending on stack-up and trace width, a two layer layout will be worse and one would hope that no recent CD player (the last say 25 years) is so bad that they have used a 2 layer design. So my conclusion is that most will be pretty much near the desired target impedance. Then if you use RCA connectors you hit an impedance mismatch as these are not 75R, then if the cable is a 75R there is a second mismatch, third is the RCA connector at the far end of the cable, then the receiver and how that is terminated. No cable will correct impedance mismatches, just add its own, correct line termination WILL correct things though.
This correcting impedance's is becoming a oft used phrase, with many of the USB hubs that are being sold using it as a bullet point and claiming major sonic benefits. I find it hard to believe that competently designed gear would be so badly designed that all this tweaking brings such perceived sound improvement when playing with what is just a stream of data. But I suppose it gives people something to sell and others endless fun playing with cables, it just seams to detract from the real issues though.
Further for SPDIF it can be considered to be a short transmission line so as I have said the correct termination impedance will mask any impedance mismatches down the PCB traces and cable, so even a bit of wet string could be used (well basic figure of 8 bell wire, on a similar industrial interface, Manchester encoded approx we got a signal to go 200m). So correct termination and you don't have to buy a $2000 exotic cable just a few cents on a resistor.
Strong belief at work.... 🙂
I link docs like that _because_ i´ve read it and because these contain the information needed for confirmation.
ECMA 130 is accompanied by ECMA 119, which contains the information about file structure and volume info....
Which i consider as another nice example of confirmation bias at work. 😉
As i´ve stated that at the basic layer, data is stored on the CD-R exactly the same way as in case of CDDA, what else would you expect???
As said before, the additional error detection and correction properties are invoked a layer above.
Information about some of these additional properties you could have found in Annex A and Annex B (both marked as normative).
A few pages before, the standard is quite clear:
"b) a Sector Mode byte in byte position 15. The setting of this byte shall be as follows:
If set to (00) : This shall mean that all bytes in positions 16 to 2 351 of the Sector are set to (00).
If set to (01) : This shall mean that all bytes in positions 16 to 2 063 are user data bytes and that the
bytes in positions 2 064 to 2 351 are set according to 14.3 to 14.6 below. Thus the user data is protected by EDC, ECC and CIRC. "
On page 14 you´ll find a description of a sector according to mode 01.
Postscript: as a matter of form, i should add, that ECMA 130 provides an additional mode 02 for "digital data" (please remember that ECMA 130 differentiate between "digital data" and "digital audio") where the data is structured in sectors the same way as before, but the user data is _only_ secured by _CIRC_ (means without EDC and ECC)
It is a bit surprising that nevertheless you don´t understand why i insist that the misleading term "ears only" should be banned.... 🙂
The terms: 'ears only', 'peeking' and several others are meant to bias the listener to either adopt or reject certain audio input. They are not objective terms.
They are meant to show how people who actually trust their ears and have integrity operate.
Chris and Jakob2 I edited my post with an apology almost immediately. I found a reference that was wrong and ran with it, that was not smart nor productive for that I am sorry.
The CDROM standard is not relevant in any case except I suppose FLAC on CDROM would overcome the overhead and the error problem pretty thoroughly.
I remain disappointed in how hard it is to get a measurement of actual data integrity in normal use. You are correct the V bit has no standard use so the data remains buried inside.
Again sorry.
This is a two part statement and I do not understand either part. Can you explain?
- Status
- Not open for further replies.