Come on Waly what would Jello do. I have my t-shirt do you?
https://www.youtube.com/watch?v=FXloYCC3iyc
Last edited:
Hi Waly,
You are right. At some point someone had to code it. At that point in time it is software - changeable. By the time we "see" it, it is firmware.
-Chris
You are right. At some point someone had to code it. At that point in time it is software - changeable. By the time we "see" it, it is firmware.
-Chris
VHDL (verlog, or other HDL implementations) is not code, it is a hardware description language. It produces hardware logic implementation of the code. you are confusing it with firmware which is easily changeable.
The CIRC encoder/decoder are hardware. The code is hardwired in the design. If you wanted to re-program, you would need to rewire the building blocks.
I avoided posting the original AES version, too much of an eye chart. We need to remember this all had to be done in 1980's technology. Before we leave the bit perfect discussion...
Last edited:
1st link: all the Internet Archive Wayback Machine snapshots, lead to broken links, most probably due to a major database reconstruction (and it’s getting worse)
CourseWork Retirement Information | Canvas
I also can’t locate it manually in Stanford archives.
btw,Scott you are familiar with Python, this may be of interest to you.
Audio Signal Processing for Music Applications | Stanford Online
2nd link:
https://web.archive.org/web/2003041...cs.co.uk/PcHardware/CD-RW/RecordMethods.shtml
3rd link:
https://web.archive.org/web/20020614083245/http://www.mscience.com/faq28.html
4rth link:
https://web.archive.org/web/20030608203939/http://www.cs.tut.fi/~ypsilon/80545/CD.html
5th link:
https://web.archive.org/web/20021210151739/http://www.4i2i.com/reed_solomon_codes.htm
6th link:
https://web.archive.org/web/20021211221737/http://math.berkeley.edu/~berlek/alg.html
7th link:
https://web.archive.org/web/2002120...rts/Group.1/matt_page_individual/subcode.html
8th link:
https://web.archive.org/web/2002102...ang/hotlist/cdrom/Documents/tech-summary.html
9th link:
https://web.archive.org/web/2002120...onics.co.uk/technology/cdbasics/cd_frames.htm
10th link:
https://web.archive.org/web/2002100...ronics.co.uk/technology/cdbasics/cd_specs.htm
Re C1, C2 error codes:
It is obvious that Chris and Mark refer to different error code entities when they mention C1, C2.
Mark refers to what is explained as such in the link of post #435 as well as with some software debagging programs and defined in some standards and Chris refers to the name given to specific electric output signals (error flags) coming out from some pin(s) of an IC that does error detection and correction inside a CD driver (e.g. Pin 43 of IC: LC78626KE) see page 19
HTTP 301 This page has been moved
George
I personally know the guy who developed this technology from a math and logic point of view (Kees Immink), at the time challenging his Philips and Sony coworkers to transfer it to silicon.
He is still active, we meet sometimes at AES section events. I think he has at least three honor degrees from Japanese universities. One of very few scientists ever to receive an Emmy.
His latest feats are similar concepts used in video encoding. SACD is old hat to him ;-)
Jan
Last edited:
The CDDA (compact disc digital audio) standards contain a surprisingly low amount of requirements on the reproduction gear and the actual audio content of the CD as well.
Instead they concentrate on the physical properties of the disc (and the optical unit required for correct read out) and the general specifications of data format, sampling rate and error detection/correction which must be used.
See for example the audio content, it´s just specified as 16 bit encoded linear in 2´s complement format with a sampling rate of 44.1 kHz, either with preemphasis or not.
Apparently it was of utmost importance that every disc - made according to the standard and therefore marked with the "compact disc digital audio" logo - will be played in every player - made according to the standard and therefore marked with the "compact disc digital audio" logo - while leaving the specific properties of the players to the manufacturers.
Therefore the mdiocre players, mentioned by anatech, can exist and do not violate the standard.
The situation for S/PDIF, AES/EBU (IEC 60958 - x) is similar but in addition a bit unfortunate, as the format includes only one so called "validity bit" which should indicate if the data is reliable or not.
Although the meaning seems to be unambigious, in fact it isn´t-
The authors of the IEC 60958 wrote so nicely:
" Originally, the definition of validity was, in both industry standards, that it indicated whether or not the associated audio sample was “secure and error free”. Although, at first glance this may seem a clear definition, in practice it has led to important practical problems. It is unclear how the receiver should interpret this. When the sample is signalled not to be in error, it is not clear
whether the transmitter has performed a successful concealment. If a sample is signal led in error, it is not clear whether the sample should be passed on unchanged, concealed or muted."
(lEC 60958-1:2004, Annex 4 (informative) )
As usual, it depends. The inventors think it is like this:
http://www.diyaudio.com/forums/attachment.php?attachmentid=569131&stc=1&d=1473519591
(Hoeve et al. , Error correction and concealment in the Compact Disc System,
Philips Tech Rev. 40, 166 - 172, 1982)
Oh yes, Immink did a lot of work some informations about him and his publications:
http://www.turing-machines.com/indeximmink.html
Attachments
Last edited:
Impressive!
What you breath, eat and drink up there for to become so inventive? 🙂
George
Dutch beer, Dutch girls, Dutch cheese 😎. Not necessarily in that order.
Seriously, I think his main insight was that he was not dealing with audio ;-) He is a mathematician at heart, and if you want to pack the max number of bytes on a given technology carrier, and wanting to retrieve them error-free, you're dealing with math, of course.
What the data represents is irrelevant at that stage.
BTW Listening to a pair of Kii Three's at the moment. Am going to do a review for AX.
Jan
This should be fairly easy to test.
Insert a potentiomenter of say 500R in series with the data line, and a shunt pot of say 50K in series with the 75R to ground at the receiver.
Adjust both pots to 0R. This is the ideal transfer match. Now twiddle the pots and see what happens to the audio coming out of the D/A converter.
I personally will bet there is no tonal shift, but rather there will be a point where data will become corrupt and dropouts (interpolations) will occur. Beyond this point data corruption will increase as will dropouts. Basically sound goes to $hit.
I see they made the completely correctable clear. They also seem more optimistic than SY. Any data on BER performance of players? The falloff is rapid and I suspect e-3 is nearly pathological.
I'm surprised that no one commented on the fact that CDROM does not in fact use a more robust error correction. This should have been obvious from the overhead.
- Status
- Not open for further replies.