Talk:Compact Disc Digital Audio

Range of values

From the article, prior to my edit: "Sample values range from -32768 to +32767, which map from -1.0 to +1.0 when converting to float. (Is this correct? It may be that the lower bound is -32767)". The question at the end belongs in here, rather than out there. So now it is. --203.206.183.160 13:05, 20 July 2006 (UTC)

Don't know the answer myself, but this might help: It depends on the format in which the integer values are stored. A two's complement representation will range from -32768 to +32767, whereas a signed integer representation will have a lower bound of -32767 (the total number of integers is the same in any 16-bit representation, but signed integer has two zeros (+0 and -0), so two's complement allows one more number. --203.206.183.160 13:05, 20 July 2006 (UTC)

from dave:
Right that's my point exactly. What *is* the red book format stored on a standard CDDA disc? It makes life much easier if it really is -32767..+32767, that way you just divide by 32767 to get your float value. Else you have to do this:

valF = <integer val>;
if (valF == 0) {
  valF = 0;
} else if (valF > 0) {
  valF /= 32767.0f;
} else {
  valF /= 32768.0f;
}

Which is cumbersome. Also you can't perfectly cancel an integer signal (via subtracting it's negative) due to aliasing (since the ranges for positive and negative are actually different). There must be some red-book aware guru who can settle this matter? --davec 21:58, 31 July 2006 (UTC)

I don't understand what the relevance of interpreting the numbers as floating point actually is? The integer number representation represents a digital code value that is fed to a digital to analogue converter, which then converts the digital integer value into an output voltage or current. D-A converters do not - not that I have ever seen - take as input any kind of floating point numbers. They use either signed or unsigned integer numbers.

The only reason you might want to convert the integer form to floating point is if you wish to do some further processing such as the application of digital filtering algorithms.

And if you really do need to represent the sample value in floating point form, then you're only losing out one code value in the range of 65536 possible codes, and it's a maximum level value of 0dBFS, maximum volume level which hardly anybody mixes/masters the music at that level because it will end up being dangerously loud, so the small error in format conversion from integer to floating point is of little concern.

I'm not asking for your opinion or your interpretation of it's relevance. I'm asking *what is the spec*. If you know, just say what it is, if you don't know, well, then you don't know. So I ask again, What is the spec? davec 23:11, 20 June 2007 (UTC)

Look, just do the math. A sample has a depth of 16 bits. Therefore, there are $2^{16}=65,536$ possible levels of amplitude which can be represented. This makes it clear that the range cannot be only -32,727 to +32,767. Since the integer is two's complement signed, it represents values from $-2^{(16-1)}$ to $2^{(16-1)}-1$. Therefore, the range is -32,768 to +32,767. tgies 06:01, 22 June 2007 (UTC)

I don't know what this floating point stuff is about, but the data portion (the actual samples, 6 per frame) is PCM as in a WAV file and is (correctly stated here) as ranging from -32768 to 32767 (the sampleing order is interleaved but the samples are the same as WAV). jrg 17 July.

All of this talk about conversion to float is useful for certain kinds of processing of data after it is taken off the CDDA disc, however, there is no specification in the Red Book for such a conversion because the Red Book is not concerned with conversion to other formats, only with the native format of CDDA. It would be pointless for a specification such as the Red Book to spend time talking about conversions to other formats that are not used in CDDA. The proper conversion is to divide by 32768 for both positive and negative numbers. Don't worry that you cannot get precisely +1.0 with 32767/32768. The industry standard is to divide by 32768 because that does not create quantization noise, and because it is completely reversible without distortion. BrianWilloughby (talk) 07:50, 27 May 2009 (UTC)

I would say just to let your DAW handle it and not fuss about the specifics, as it will have already been worked out by someone smarter and more knowledgeable, and you only really need to know if you're writing a DSP plugin. However, I expect that cancelling out inverted waves is done, as it's an internal function and we therefore know what's going on and can guard against fencepost errors etc, by working on the basis that there is no actual "centre" sample value with signed ints and treating them as if they're all offset "upwards" by half a sample. Or in other words treating them as unsigned for the purposes of addition, subtraction and inversion. So there is no 0, only -1 and +1 (well.. -0.5 and +0.5, ranging then to -32767.5 and +32767.5). I have a feeling that the two's complement notation, or at least the way the software handles the representation of waves within it, may deal with this automagically anyway, so when you invert a one-sided wave that only flip flops between 0 and +32767, the inverted representation will instead flip between -1 and -32768, and if you then cancel it against the original form, you get a long string of -1s. Or it may just be convention to never assign a -32768 value, instead clipping to -32767, accepting that minuscule loss of resolution as "worth it" for the sake of simplicity and correct wave mathematics (so your inversion becomes 0 to -32767, can't be amplified to -32768, and adding the original and inversion together will result in a line of 0's).

As for conversion to float... the only reason you would bother with that (in 32-bit form which means 23 bits of mantissa and 8+1 for the exponent & sign; or even just 24-bit fixed point which has 16-bit precision plus the exponent) is to get increased representional range, greater precision, or both. You should, at worst, be able to directly convert the integer data to fixed/float decimal mantissa + sign with no loss of accuracy (as they're all binary formats that include some kind of direct signed-value representation), fixing the exponent/multiplier/point position at "1" and bitshifting to backfill with 0's if needed. Converting back, just throw away the exponent/etc and truncate any padding digits. If you want it to be fully invertable, do whatever's necessary after the first conversion stage to add the equivalent of half an integer step, as above, then remember to subtract that again before converting back. Piece of cake. 51.7.16.171 (talk) 00:45, 29 July 2019 (UTC)

Mastering formats

The Sony PAL format U-Matic 3/4" videotape was the original media for mastering Redbook Audio. The 44.1Khz sampling rate is directly related to this choice of media, not to any considerations about Nyquist Frequency or any of the other reasons given for why 48Khz was not chosen, which was the sample rate used for most other digital audio in the then new field.

http://www.edinformatics.com/inventions_inventors/compact_disc.htm

A Sony 1610 or 1630 PCM digital audio converter for U-Matic tape can store 6 samples (3 for each stereo channel) per video line.

PAL video (as recorded by a U-Matic VTR) has 294 lines and 50 fields per second, which gives 44,100 samples/second.

NTSC can store more samples per second due to its higher frame/field rate, but its higher capacity wasn't used. The most likely reasons being that more countries use the PAL TV standard than the NTSC standard, which would make PAL U-Matic VTR machines more common, and that the higher rate attainable would allow fewer minutes of music to be stored on an Audio CD.

NTSC recorders were not used - 60Hz monochrome units were. While 60Hz video has more frames/second, it has fewer lines/frame. According to John Watkinson in "an introduction to Digital Audio" (section 2.7) both 60Hz and 50Hz recorders give the same 44.1kHz figure. 60Hz video has 35 blanked lines while 50Hz video has 37. At 3 samples per video line, 3 x 60 x (525-35) / 2 = 3 x 50 x (625-37) / 2 = 44100 TheGiantHogweed 08:22, 18 July 2007 (UTC)

Right theory but not quite right numbers - you only get half the total lines per field; the correct way of writing it is 262.5 x 60 and 312.5 x 50 (interlace fields) - or, 525 x 30 and 625 x 25 (full frames). Thus with the same data per frame we arrive at the previously stated 6 samples / 3 stereo samples (ie 96 bits) per line, which is a more efficient use of the tape but still well within the reliable recording capability of a typical VTR. 490 active lines at 60Hz and 588 at 50Hz (more correctly 245 and 294 per field) does seem unusually high, fwiw; I wouldn't be at all surprised to find it is instead 7 samples per line, using only 420 or 504 active lines, which would then be easier to visually check on an overscanning monitor as it would just clip within the usual borders - and would be more reliable as the active area is kept well within the outer limits of the azimuth head sweep rather than risking running over into the potentially distorted edges.

The maths still work for that, and a few other choices besides, as a key thing about the 44100Hz figure is that it's divisible by a surprising number of small factors (though, oddly, not 8... but each sample being two bytes, and a stereo pair, gives us some extra binary divisibility to cover that), most crucially both 50 and 60, but also 1 thru 7 plus 9, 10, 12, 14... so there's a little flexibility in how you set up your recording, either pushing the limits of linecount with only 96 bits per line, or being more conservative whilst cramming 112 bits per line instead. And it probably makes the use of either 14 or 16 bit samples in test rigs more convenient, before the final choice was settled on.

All in all the real reason 44100 was chosen was that it was likely the lowest number (thus providing greatest recording time within a fixed data capacity) that both satisfied those mathematical requirements for being recordable on standard videotape without needing a huge data buffer (only one large enough to cover the blanking - whether 35/37 lines, or 105/121 lines, running FIFO to gradually build up the head as the data reads off the tape slightly faster than needed, then emptying at a fixed pace during blank, and vice versa for recording...), and was sufficiently far above the minimum requirement of 40kHz (for 20kHz headroom) that a relatively simple analogue low-pass filter could be used to guard against nyquist foldover distortion; possibly there was an "at least 10% guard band" rider on everything, meaning that although 43800Hz would also divide into 50 and 60 just fine (but not give a clean whole number of active lines at 60Hz with 96 bits/line...) it simply wasn't high enough... and also lacked the same amount of small-factor divisibility. 43200Hz would actually have been a nice alternative as it would fit in the digital-standard 240 or 288 lines per field at 96 bits/line (and is the first stop below 44100 where everything divides cleanly), but presumably 3200Hz just wasn't enough filter overhead, or they wanted to use every last bit of the available tape capacity? Going the other way, you'd have to go all the way up to 45000Hz, and then you run into problems of actually fitting the data on the tape, as well as hampering the playing time or requiring finer recording pitch, so higher cost and lower reliability, and maybe increasing the necessary read hardware and decoding train - at 44100Hz sampling rate, it's already having to read off the disc at a little over 4.32MHz (or Mbit/s), which would have taxed most microprocessors of the time.

So 44100 may look like an odd and rather random number, but it's the only available neat fit for a variety of different constraints being put upon the sampling rate.

A side note - the 44056Hz mentioned as a Sony option in the main article seems to actually have made it into real world use (and I've seen it as an option in some older wave editing software, for example); it may have been provided for use with less specialist video decks converted from NTSC Color use, where the field/frame and indeed line rate is slightly reduced as a means of reducing color carrier interference with the underlying black and white image - the reduction is to 1/1.001 of the original figure in all cases... so a 15750Hz line rate becomes 15734.27Hz, 60Hz field rate becomes 59.940Hz (or 30Hz > 29.970Hz frames), and a 44100Hz digital audio recording rate has to be decimated to 44056Hz (or 44055.944Hz to be more precise) to stay in sync with the recording medium. Systems working with NTSC color often had all of their timing referenced to the (315/88)MHz (ie ~3.58MHz) colorburst crystal, so reducing the audio sampling rate by an imperceptible amount (thus speeding up the playback in kind, after using the samples 1:1 at the full 44100Hz in mastering) was the easier option vs attempting to change the speed the recorder ran at, which would likely mean replacing the crystal with a 0.1% faster one (3.583125MHz instead of 3.579545MHz, if you could actually find it) then tweaking various analogue tuning pots so everything was guaranteed of staying in synch...

(Curiously, 44055.944 is (315/88) divided by 81.25; so if you used the at-least-as-common 14.318MHz crystal from which multiple different clocks including the colorburst were routinely divided, a 1/325 division would get you the exact sampling rate needed to feed the recorder... and presumably the same would hold for a 14.3225MHz to produce 44100Hz, if you could find one of course... though a much higher frequency clock would be necessary to get a clean division to drive the actual bitclock, at 32 bits per sample... then again, each line has a certain amount of blanking as well as each field having vertical blanking, so as long as your sampler could reliably take a 2x16 bit snapshot of the audio voltages when triggered by the /325 input clock, you could use whatever arbitrary divisor was a close match for using as much of the available tape as possible for serially cranking out the 32 bits so generated on the output side; you need at least 1.8MHz at 60Hz (96 bits in 53.33us or less) and 1.829MHz at 50Hz (52.5us), at least if we stick with absolute standards compliance (otherwise slightly lower clocks are possible), corresponding to dividers of 1/8 if we violate the standard a bit (1.7898 or 1.7903MHz = 53.64 or 53.62us), or 1/7 to play it quite a bit safer (2.0455 or 2.0461MHz = 46.93 or 46.92us, potentially within the horizontal underscan area)... ignoring for the sake of simplicity the higher rates and better use of the available tape that would be possible by using 28.6MHz/15, or a 4.43MHz (or 17.73MHz, 35.47MHz...) PAL colourburst crystal in a 50Hz machine.) 51.7.16.171 (talk) 23:59, 28 July 2019 (UTC)

The 1610/1630 U-Matic (or Umatic) audio CD mastering format has held on until the past 2 to 4 years as the standard that CD mastering companies accepted above all others. As the U-Matic VTRs have gone out of service due to lack of replacement parts, other digital tape formats have become more popular for mastering. Yet even those are becoming less used due to the improvements in CD recorders "burn" quality at low speeds and the improvements in error checking at the mastering stage.

too technical

I'm adding the {{technical}} tag to this page. The meat of the article, describing the nature of the spec, needs some expansion I think. Perhaps a little about how the spec is used by manufacturers. I'm a relatively technical person and I was completely bewildered by the middle passage.Jasongetsdown 22:31, 15 November 2005 (UTC)

There is no meat in digital audio - please explain your assertion. — Preceding unsigned comment added by Qfissler (talk • contribs) 21:40, 3 March 2022 (UTC)

merge

This article should be merged to Rainbow Books. Please comment at Talk:Rainbow Books. —Quarl ^(talk) 2006-01-15 11:42Z

I think this is a bad idea. The Rainbow Books page has its own content, and serves as a nice index to the various Book pages (Red Book, Yellow Book, etc.). There is no reason to merge it in here, and doing so would undoubtedly cause a loss of information (contextual or otherwise) in the process. I am strongly against. --Kadin2048 18:10, 23 May 2006 (UTC)

Copied comment (above) to Talk:Rainbow Books where discussion is held --H2g2bob 15:57, 22 June 2006 (UTC)

rm. tag --H2g2bob 21:45, 25 June 2006 (UTC)

I agree with Kadin2048 - I did not know of the term 'Rainbow books', only of the 'red book' spec (and of the various books describing the postscript spec, but that's not related to audio, although it may be included in the 'Rainbow books' series..). At best, a redirect (preferably directly to a section, if that is possible with WikiMeda) from 'Red Book' to a section of the 'Rainbow Books' article should be maintained.

De-facto vs. specified

"It also specifies the form of digital audio encoding (2-channel 16-bit PCM clocked at 44100 Hz). These parameters have become something of a de-facto standard."

How can a standard be both specified and de-facto? Tgies 06:07, 20 February 2006 (UTC)

I think what the author was trying to say may have been something like:

"It (the Red book standard) also specifies the form of digital audio encoding for audio CDs (2 channel stereo 16-bit PCM encoding at a 44.1 kHz sampling rate). These parameters have become something of a de-facto standard for all digital audio." T3h933k 01:30, 22 March 2006 (UTC)

16 bits per channel or 16 bits total?

This article implies that CD audio uses 16 bits per channel (in the maths calculating the bit-rate)... However, the bit rate that they come up with would mean that 74 minutes of audio (before error correction codes) would require 783MB to store ( 1411.2 * 60 * 74 / 8 = 783216KB ). If it were 16 bits for the two channels, this would mean it would require only 392MB before error correction codes, which seems more realistic given that a 74 minute CD holds 650MB of data. Can anyone more knowledgable comment on this? Thanks. -- David Scarlett^(Talk) 07:01, 28 April 2006 (UTC)

Nevermind, apparently it is 16 bits per channel and you can fit more audio data than general data due to different error correction schemes, which would explain why the audio data can take up more than the generic data capacity of the disc. This article explains it. -- David Scarlett^(Talk) 12:31, 28 April 2006 (UTC)

This is a very old error but I think it stands correction to avoid confusing the casual browser: CD audio data rate is 16 bits per channel, two channels, at 44100Hz, equalling 176,400 bytes per second, end of. On top of which you may wish to add 7,350 bytes per second of subcode, but this is usually considered as an out-of-band overhead, the same as the error correction, added in automatically by the mastering software or the hardware itself. Unless you're doing fancy subcode tricks (messing with index points, incoporating CD+G or kareoke data etc), it's an irrelevance, and all that matters is the audio data itself. In which case, if we can officially fit 79m57s on a disc (79m59s74f minus a 2-second lead-in and some other minimal fluff), the amount of meaningful audio data you can transfer to it from your hard drive is 4,797 seconds x 176,400 bytes = a gnat's hair under 807MiB. The actual amount of data encoded on the disc, as raw pits and lands, is much higher, but that matters little to the lay consumer, no more than the details of the quite complex encoding of their hard drives (themselves using "wasteful" error correction multiplex encoding and the like, thus having a raw bit capacity well in excess of the stated useful data capacity), and it can vary depending what you choose to include or exclude from the calculation. The important thing is the disc can contain 79m57s or 807MiB of audio, or 359,775 sectors x 2048 bytes = 702.68MiB of CDROM data (though we might in that case be able to use the lead-in, at least to store the FAT, pushing the total to more or less exactly 703MiB), including the variable-length ISO9660 filesystem.

With the example of a 74-minute disc (and assuming exactly 74m00s), that's 74 x 60 x 176,400 = 746.39MiB (I assume your "783MB" was decimal megabytes?!), not including subcode or error correction, or 650.39MiB of CDROM data.

FWIW, the subcode is worth a little over 31MiB on a 74m disc, and around 33.5MiB on an 80m. The error correction (operating only on the audio, not the subcode) inflates the total quite considerably - to 540,225 bytes per second regardless of actual data format (audio, ROM, VCD...), or over 2.2GiB for 74 minutes. With 8-to-14 modulation on top, the raw data rate hitting the laser is 945,393.75 bytes per second (so just keeping within what might have been a processing system limit of 1mbyte or 8mbit/s), and roughly 4000MiB overall for a 74-minute disc.

What any of this means in terms of "bits total" per sample is left as an exercise for the reader, though we CAN say that it's "32 bits total" per audio sample. 51.7.16.171 (talk) 13:31, 28 July 2019 (UTC)

"Text" logo

File:Cdat.jpg

Can someone add to the article what the "Text" caption means in the Compact Disc Digital Audio logo? (see right.) Tempshill 01:50, 19 June 2006 (UTC)

Maybe it is "CD-Text" as describe at http://www.true-audio.com/Compact_disc --Joshtek 14:32, 20 July 2006 (UTC)

Standard?

Disregard

 – The article was renamed to "Compact Disc Digital Audio". Chealer (talk) 23:10, 6 March 2013 (UTC)

The Red Book is the informal name for the Compact Disc Digital Audio specification (more commonly known as CD-Audio). While the word "standard" is quite similar, it doesn't quite mean the same thing. Products such as CDs are produced to meet a specification. When they are tested, they either meet the specification or they don't. Specifications are specific. Standards can be something less specific (de-facto, etc.). I would suggest that this article be renamed Red Book (CD-Audio specification). Tvaughan1 13:36, 28 August 2006 (UTC)

Removed obsolescence section

FYI

I removed the section arguing that CDs are obsolete due to the popularity of iTunes/ iPod. This section cited no sources and seemed irrelevant to the topic of the blue book standard.

Licensing confusion

Is it really $5000 to license the standard itself? I am guessing it's $5000 for a manufacturer of audio CDs to implement the standard. Anyone can get the publication for $200. —mjb 23:01, 21 February 2007 (UTC)

Frequency response?

Does Red book indeed specify frequency response? It seems rather illogical.

The sampling frequency of 44 kHz implies a maximum sound frequency of 22 kHz. I have no idea where the lower limit comes from, but a lower could have been imposed to avoid damage to the user's equipment (Turritus 12:26, 24 April 2007 (UTC)).

22kHz is a theoretical upper bound for the frequency content, but practically, not acheived. The actual boundaries of the frequency response depend on the CD player and could be quite difficult to compute. Perfect reconstruction up to 22kHz would require the CD player to compute a large series of Sinc functions for every sample. See Nyquist–Shannon sampling theorem for a full explanation. Sirhans 22:19, 2 May 2007 (UTC)

The 20Hz lower limit is likely not a technical limitation of the red book standard, but was simply added because it's the generally-accepted (and often-cited) lower limit of human hearing -- the point below which supposedly 50% of people cannot hear the sound.

I certainly think frequency response is an incorrect choice of words for the concept... an electrical system has a frequency response, a set of data does not. A CD is a collection of data and therefore the latter.

By that analogy, so is a vinyl record or cassette. Irrespective if they contain data or not, they become part of an electrical system when played back. Therefore, frequency response of the CD format is absolutely a correct choice of words. Vinyl does not go down to 20hz, for example. —Preceding unsigned comment added by 71.62.11.217 (talk) 23:53, 29 September 2007 (UTC)

I'd argue against that. There's a fundamental difference in the way which data is recorded onto all three of vinyl, tape and CD, with a progressively reducing reliance on the comparative amplitude of the input signal vs the previous state. Recording and playback on vinyl is entirely dependent on ongoing deflection of the needle one way or the other vs where it was before, and below a certain frequency you can't be sure what's useful signal and what is simply the effect of a slightly imperfectly punched centre hole, and the system inertia will be insufficient to maintain a sideways deflection of the play needle... instead the entire head and swingarm will deflect, as can be easily seen with an off-centre record, or when the runout groove is reached. A sufficiently low input frequency simply can't be reproduced by most systems, as - on top of the attenuation imparted by RIAA EQ - the recording head will suffer a compensatory deflection against any attempt by the needle to maintain a particular position for any length of time, and the playback head will tend to follow whatever subtle evidence is left behind instead of allowing its own needle to remain deflected, and instead of getting infrasound you'll just see the head shaking around. It tends towards having the needle resting at centre, and if it's not being vibrated sufficiently fast then it may as well not be moving at all.

It's late and I can't think of the proper reason, but I think there's some issue with trying to record an unchanging (which for the local patch of tape, is true with a suitably low frequency sound) input voltage across a particularly wide swath of the medium, and is why a high frequency AC bias voltage has to be applied to the record head. The electromagnet coils in the rec head may well be able to produce a static field and impart that to the tape, but like the record, the passive coils in the play head require a *changing* magnetic flux under them to produce and maintain any kind of signal, so if there's a long run of a sustained or only slowly changing voltage under them, they will, like the record deck, fail to produce a meaningful output signal, simply being slightly deflected by the most rapidly rising/falling edges of the subsonic signal, then tending to settle back towards "zero".

The CD situation is different. It's a stream of digital data which we can directly control if we want, and that isn't affected by steady states or low freuqencies that are close to them on the recording or playback side. Whatever voltage you provide the input side with, and the pattern through which it moves and how far, fast or slow it does so can be recorded entirely faithfully as discrete numbers (each one an individual sample of the incoming voltage at that 1/44100th of a second), and crucially output as the exactly correct voltage and its pattern. It's good enough that people have made albums that can drive oscilloscopes to draw images rather than play music. Or various ultra low bass test discs, or demos for use in SPL competitions or just for challenging the very lower limits of what your subwoofer can output ... even if you can't hear it properly, you'll sure as heck still *feel* that 5 to 10Hz maximum amplitude sweep... CD can recreate it accurately, tape may have some difficulties, vinyl has no chance.

So, really, the system may have a fairly rigidly defined maximum treble frequency (22.05kHz - or 20kHz if you're following the official sources to the letter), but it doesn't really have a lower bound. It's simply whatever the mixing desk is able to deliver to the burner / mmastering machine's input in terms of varying voltage... 20Hz is nothing, you could easily apply a single-cycle biasing waveform that oscillated over the entiety of an 80-minute disc, and recover its shape exactly, when a tape playback might not reveal it, and vinyl wouldn't represent correctly in any way at all. 51.7.16.171 (talk) 01:06, 29 July 2019 (UTC)

Kbps

Just a little note: According to our article on Kbps (data unit, following the disambiguation), a Kbps = 1000 Kbps. This is the standard typically used for digital audio and storage, so I think we should follow it. I recalculated and changed the nominal bitrate in the article from Kbps == 1024 bps to Kbps = 1000 bps. 4.242.108.211 (talk) 20:03, 25 March 2008 (UTC)

I notice the article likes to often use different units: kbits here, KiBs there. Please unify. Jidanni (talk) 00:52, 20 May 2008 (UTC)

The different units used are appropriate in context. tgies (talk) 09:33, 20 May 2008 (UTC)

Let's back to basics. Uppercase "B" stands for "Byte" and lowercase "b" stands for "bit". 1 single Byte = 8 bits. In computers, one "Kilo" (2^10) stands for 1024 and not 1000. Then, 1 KB (Kilobyte) = 1024 Bytes. That said, 1KB = 8Kb. Allan Davidson (talk) 14:37, 3 April 2013 (UTC)

Is the Red Book standard still being used?

The article doesn't say something as simple as that. "Maximum playing time is 74 minutes (including pauses)", however music CDs today can have 80 minutes, can't they? This leads to anyone who doesn't know too much about it to understand the Red Book is an old standard.--Jim88Argentina (talk) 03:32, 3 February 2009 (UTC)

There seems to be some confusion, possibly because the web is much younger than the CDDA standard itself. Many online sources of information quote the CD-R limit of 74 minutes as if it is the limit for CD as well. The story of the origin of the play length has also been retold so many times that it seems impossible to reference an original source. I have edited the article to cite a 1987 book which documents 79.8 minutes as the actual limit of CD. I remember being disappointed that the first CD-R blanks would only hold 74.0 minutes when I already had discs in my collection as long as 79.5 minutes. Today's CD-R blanks stretch the specifications a little tighter to reach almost 100 minutes, but the CD glass master typically has the 79.8 minute limit. The time code format can refer to 99 minutes, 59 seconds, and 74 frames, but that is different than the physical track length. Part of the difficulty is that the Red Book gives the size of the disk, the size of the spiral track, where it starts, and its pitch, but not the actual total length. No number is mentioned anywhere. The math to calculate the actual limit based on the specified nominal values is actually quite complicated, but I'm sure it involves pi and some sort of integral. BrianWilloughby (talk) 11:07, 26 September 2009 (UTC)

I am not qualified to do the edit myself, but this figure (79.8 minutes) needs to be removed or clearly specified as Red Book first edition (1980) unless a corroborated 1999 source can be found. The lone source identified (in BrianWilloughby's footnote) is a 1987 document, although the number evidently dates from the 1980 first edition of Red Book: see http://www.diyaudio.com/forums/digital-source/199800-burning-cds-older-players-3.html. The article states elsewhere that the 1980 standard is wholly superseded by the 1999 second edition, so it seems essential that the latter alone should be cited. 700MB/80-minute disks had been introduced prior to 1999, so unless the second edition standards do reflect higher limits, the article should also make it clear that Red Book "standards" were established for 650MB disks and have never been updated for the present 700MB format. That at least might encourage mastering services to be less fearful about near-threshold audio-lengths. Meanwhile several sites claim 79:57 as Red Book-compliant, e.g.: http://www.about-audio-mastering-software.com/red-book.html and http://recording.org/mastering-engineers-forum/21816-red-book-audio-cd-help-urgent.html. The latter's "mastering-engineers-forum" moderator asserts that Red Book does not specify a limit. BrianWilloughby's statement above, "the CD glass master typically has the 79.8 minute limit", is similarly problematic, as greater lengths are routinely accommodated without apparent mishap (are there documentable playability issues on 1980s CD readers?).ChuckH2D (talk) 05:42, 9 February 2012 (UTC)

Rename article to Compact Disc Digital Audio

The following discussion is an archived discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

No consensus to move. Vegaswikian (talk) 22:11, 20 April 2010 (UTC)

Red Book (audio Compact Disc standard) → Compact Disc Digital Audio — Relisting  Ronhjones  ^(Talk) 00:29, 3 April 2010 (UTC)

For reasons as discussed below. Ham Pastrami (talk) 02:37, 19 March 2010 (UTC)

In my opinion this article should not be called as Red Book. Red Book should have only a brief description of what does contain that book. The other articles of the Rainbow Books, contain a small description, and then, an article of the physical disc itself such as CD-ROM (yellow book) , CD Enhanced (blue book), etc. The physical disc is named "Compact Disc Digital Audio" not Red Book. --Juan D. (talk) 03:34, 14 February 2009 (UTC)

Agreed. Red Book is technical jargon. The proper name of the medium is Compact Disc Digital Audio (CDDA). Supposedly the article is interested in all aspects of the format, including, and not limited to, the Red Book specs. This would also be an unambiguous name for the subject.Ham Pastrami (talk) 02:22, 19 March 2010 (UTC)

• Oppose this article is concerned with red book, CDDA is not necessarily red book compliant, and a larger article covering CDDA should be built, covering addition of data tracks, copy protection, etc. These discs still are allowed to the carry CDDA emblem, but are not red book. (there are also the discs that are not allowed to carry CDDA, like DualDisc, but are audio dics...) Further, the physical disc is the same for yellow book, blue book and red book, it is the CD, CD-R or CD-RW. The encoding standard is different. 76.66.192.73 (talk) 20:42, 27 March 2010 (UTC)

  Why should there be a "larger" article for CDDA when the red book spec is an obvious subtopic that can be included as part of the article? There is no cause for a split. DualDisc is neither red book (as stated in the article you linked to) nor CDDA so it's completely irrelevant to this discussion. Also, in spite of your claim to the contrary, the audio CDs that do not conform to red book are NOT allowed to use the CDDA logo, as with Copy Control. So do you have any evidence to support your rationale? Because so far a cursory examination disproves your claims. Ham Pastrami (talk) 07:03, 28 March 2010 (UTC)

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Pre-emphasis

Some early CDs seem to have preemphasis applied to improve SNR, sometimes (but often not) signified by some flag in the TOC. Early CD players often had a light to show if preemphasis was present and would apply appropriate filtering, but I'm not sure if modern players do and most ripping solutions (except iTunes apparently) have no provisions for dealing with this. Is this part of the Red Book standard, and could someone provide more useful information regarding this? Found some discussions regarding this: [1], [2], [3], [4] --Zilog Jones (talk) 16:53, 7 April 2009 (UTC)

Unreliable sources

(discussion moved here from User talk:Mjb) Hello, you removed a reference to wiki.multimedia.cx on the Red Book (audio Compact Disc standard) article. You wrote: "the multimedia wiki is not a reliable source". Please, could you explain, why is it not a reliable source? MultimediaWiki is not open for any contributions. Any contributor must be approved. Mike Melason is the chief maintainer of MultimediaWiki. He monitors contributions/changes on that wiki. As far as I know, he is also the primary contributor to MultimediaWiki.--188.167.27.153 (talk) 06:47, 6 October 2010 (UTC)

I don't have to. It's a wiki, which is a self-published source. WP:SPS is clear enough. But in case it isn't, here:

The claim in question is that the Red Book "specifies the form of digital audio encoding: 2-channel signed 16-bit Linear PCM sampled at 44,100 Hz". The truthfulness of this claim is not the least bit in doubt, so it doesn't even need citations. The ones that were provided use lousy sources.

MultimediaWiki is a semi-public wiki of multimedia software engineer Mike Melanson. He might vet his contributors and edit the content himself, but that's not particularly relevant because he's not an authority on the Red Book. He may know a lot about Flash Player and xine, but he's not an expert on the Red Book. He isn't an electrical engineer who builds CD players. He's just some guy who writes software. He might own a copy of the Red Book, but if he does, then he can simply give us a reference to the Red Book itself and then it won't be an issue. So it's up to you to show that it's not a violation of WP:SPS.

Now look at the other references. The homepage of Kade "Archer" Hansson? How was that even up for consideration? It's more self-published material from a non-authority on the content of the Red Book.

And lastly, the LPCM format info at digitalpreservation.gov, is promising as a source since it's essentially published by the Library of Congress. Well, it doesn't say what's in the Red Book other than "ISO/IEC 60908...covers the use of 16-bit LPCM in compact disks." All that tells us is that 16-bit LPCM can be used in compact discs and that the Red Book says how. That's close, but not really the same thing as the claim in question. There is a footnote there which goes on to say that according to Wikipedia, the Red Book defines the CDDA standard. Yes, it's true, but...they're getting their info from Wikipedia. This is far from an ideal source.

So really, all three references are inappropriate. If you really want to keep them, it's up to you to justify them. But like I said, I don't think we even need them. It's not very important that the claim that CD audio is defined by the Red Book as 44.1 kHz 16-bit LPCM be cited at all. Is it really up for debate? Besides, if references are provided, certainly someone has the actual book and can just point to the page or section number. It seems like a no-brainer that a claim along the lines of "the Red Book says X Y and Z" should just cite the Red Book itself, not wikis, personal homepages, or poorly-worded sources that don't support the claim and that ultimately refer back to Wikipedia. —mjb (talk) 09:48, 6 October 2010 (UTC)

Thank you for your answer and explanation. The references were added to the "LPCM" (linear PCM), because previously it was only "PCM" - see this change. I don't have Red Book specification and AFAIK it is not publicly available (for free). But I know CDDA uses Linear PCM. In my point of view it is questionable if we can trust someone who will add information such as "the information is on page 567 of Red Book" - directly on Wikipedia without any other reliable source. I think it is similar to adding "unreliable" sources, because most people cannot verify it.

I understand your opinion about the sources. But in the case of missing public specification there is no other choice in some technical articles on Wikipedia. --188.167.27.153 (talk) 16:22, 6 October 2010 (UTC)

Generally, unless some other form is explicitly specified, wouldn't we assume any mention of "PCM" to imply linear uncompressed? There are other forms of course, either logarithmic / fixed-point exponential (A-law / mu-law ITU-T G.711), companding schemes that work in a similar way (NICAM, some console formats), ADPCM of course, some differential types. But outside of all those, yer typical "raw" PCM is entirely linear (as opposed to log or whatever). Though it seems to have become an affectation from DVD onwards to use "LPCM" as a way of denoting a lossless uncompressed PCM source, as opposed to ADPCM, MPEG, Dolby, DTS compressed etc... 51.7.16.171 (talk) 01:11, 29 July 2019 (UTC)

Formats greater than 16-bits

On some CDs, the packaging will mention 20-bit remastering, 24-bit, Super Bit Mapping or some such. (The mid- to late-1990s Impulse! Records catalog comes to mind.) If the Red Book standard is 16-bits at 44.1 kHz, do these other "formats"(?) have any real meaning or usefulness (i.e. what good is 24-bit, 96 kHz remastering, if the ultimate product is restricted to 16-bit 44.1 kHz)? Or are they in fact not compliant with Red Book standards? -- Gyrofrog (talk) 19:13, 18 February 2011 (UTC)

That higher bit-depth, higher sample-rate marketing hype refers to the equipment and processing that was used before or during the final conversion to Red Book format. If you take an analog source, try to filter out frequencies above the Nyquist limit (22.05 kHz), and digitize the result directly to 16-bit, 44.1 kHz, then maybe do other signal processing, there can be some measurable (but not necessarily audible) noise introduced, for various reasons. You're more likely to get better results if you digitize to a higher bit depth and sample rate, do all your other processing in that domain, and convert to Red Book format at the very end. This usually involves some kind of dither and noise shaping (Super Bit Mapping is one such method).

The Compact Disc article would be the place to mention this stuff, but the problem will be finding reliable sources. It's no problem finding "audiophile" publications that parrot press releases or make subjective claims of sound quality improvements offered by such technologies, but it's much harder to find any literature which says exactly how the technology works, what problems they're trying to solve, what their measurable effects on the audio are, and most importantly, whether any double-blind testing has proven people can actually hear the difference between identical, level-matched recordings that differ only by the use of these mastering techniques (if such things could ever be found, which I doubt). It's probably best to avoid the subject. —mjb (talk) 21:57, 18 February 2011 (UTC)

OK, thanks for the info. One wonders if the improvement in sound (for example, with a re-release) has more to do with better sound levels than with sampling rates. -- Gyrofrog (talk) 23:51, 18 February 2011 (UTC)

Some of them had a suggestion that they actually encoded a greater amount of data that could be somehow picked up by a specially designed player, SACD style, but quite how that was achieved is obscure and I don't think I ever saw a compatible player, so it's probably nonsense. The rest of them essentially just mastered to something akin to DVD Audio quality, and used a combination of noise-shaping dither plus reduced / eliminated high frequency filtering (all-digital filters allowing a very sharp cutoff just below 22.05kHz with minimal ringing, vs the original standard where the extra 2kHz was to allow for a gradual LPF rolloff, with any frequency reflection out to 24.1kHz not really mattering as it would still be in the "inaudible/ultrasonic" range and then progressively quieter at lower frequencies) to give the impression of deeper dynamic range (if you even had the equipment to reveal that and the ears to hear it) at the "expense" of greater hiss and quantisation noise up in the ultrasonic range; the technique is similar, in some ways, to the "oversampling" used to get 16-bit effective dynamic range out of a very high frequency 1-bit decoder, except in this case we're only expanding the range by maybe 4 bits out of a 16-bit decoder, using a fractional amount of spare frequency range. 51.7.16.171 (talk) 13:10, 28 July 2019 (UTC)

Files section

There were a couple items of reader feedback (see the link near the top of this page) which I attempted to address in a series of edits today.

I want to know which of the files on a commercial CD a normal CD player reads.

[I was looking for the] difference between mp3 and cd format.

I believe I got both of these taken care of by adding a "files" section which explains that there are no files on a CD, that operating systems like Windows may offer virtual files as a sort of abstraction of the CD TOC, and that the common audio file formats are actually the product of ripping.

This basically amounts to a difficult-to-source "what Red Book is not" section, which I don't particularly like having... but it doesn't really seem to be the kind of thing that the average reader can easily figure out otherwise. —mjb (talk) 07:34, 26 September 2012 (UTC)

When it all boils down, there are no files on any mass storage device. A 500GB disk is just a huge linear byte stream, starting at 0, and ending at 4999999999999. Data can only be retrieved in 512b (2048 these days) chunks. It is the filesystem, if any is written, that defines files and directories. Any linear byte stream can have a filesystem written on it. Because optical media are WORM, the best file system is of the linked list type. An unclosed CD can have more data added to the end of the linked list.61.68.71.253 (talk) 23:54, 17 March 2017 (UTC)

It's maybe a confusion from having seen VCD or DVD filestructures, I'd reckon. There are generally a certain minimum set of system / menu / structure files that are needed on those for the disc to successfully function as whatever type of video format it claims to be, and they're generally pretty cryptic and need special software to prepare. As audio CDs also require a specific burner, or section within burner software, it might be assumed that certain basic files e.g. containing the TOC, or an individual track each, are being written to the CD, wrong as that is. 51.7.16.171 (talk) 01:15, 29 July 2019 (UTC)

Data encoding section

The technical details really weren't all that detailed, nor did they really explain the relationship between the physical pits-and-lands and the LPCM audio data, which is a crucial element of the Red Book standard. I attempted to address this by adding a data encoding section, summarizing info from Ken Pohlmann's The Compact Disc Handbook, since I don't have access to the actual standard.

I also sought to clarify that the term sector comes from the CD-ROM/DAE/SCSI world and is not part of the Red Book standard, as far as I know.

This led me to the article's info about CD data rates, which I attempted to consolidate into its own section. I thought it would be interesting to add the raw data rates of CDDA, which get into the Mbps range. Again, this info comes from Pohlmann's book.

I would appreciate review of these additions, and please discuss or make corrections as needed. Thanks! —mjb (talk) 07:34, 26 September 2012 (UTC)

Thanks for your additions. I'm not aware of factual issues with your additions, but I think some of the section's content would better be in Compact discs. As I understand it, the CD started with CDDA, so the physical details of CDs were once specific to CDDA. However, since this is no longer the case, I believe we should factorize the common parts of all CD variants (CDDA, CD-ROM, etc.) to Compact discs. For example, the 3 pictures on the left would be pertinent there. Even if they apply here, I believe we should avoid duplication and just move there. --Chealer (talk) 00:56, 7 March 2013 (UTC)

Ok, I just moved two of those pictures to the CD article. I also tried expanding the data encoding sectiona bit, since it contained several abbreviations with no links and it was difficult to follow at first. I will also probably try to restructure sections a bit, since there seems to be duplication between the Data encoding and the Data structure sections, and the order of the sections currently does not follow any clear logic. Sega381 (talk) 14:03, 14 May 2013 (UTC)

I tried to address some of the shortcomings by merging duplicated information, and by restructuring some sections. However, there is still some duplicated information and I am still not convinced of the logic for the ordering of the sections. We may still want to move some common information to the CD article. Sega381 (talk) 14:47, 14 May 2013 (UTC)

Format deviations

DVD Audio is not a format deviation but a rival successor format. If this is included so should SACD, which in its hybrid form is at least compatible with CDs. Also, if such details are included in this article I suggest a new heading of Successor Formats... but where do you end? MP3/Ogg/Blu Ray Audio/etc? I suggest removing DVD audio completely. But should we include hybrid SACD since it is compatible? Derekjc (talk) 17:21, 3 April 2013 (UTC)

Storage Capacity

Under the heading 'Storage Capacity and Playing Times' there is much discussion on the time restrictions of Audio CD's, but no data that I can find on the actual storage capacity in MB. I came here, specifically to find this information, and thought it would be a "given" in an article such as this. I can only assume that it was intended, due to the title of the section in question, but somehow was overlooked.

A remedy would be greatly appreciated. — Preceding unsigned comment added by 1.178.223.3 (talk) 07:39, 23 November 2013 (UTC)

Thought I'd put my own response here. since others have done it as well. CD Audio data is made up of frames, and each audio frame is 2352 bytes in size. The original Redbook standard defines exactly 74 minutes as the maximum duration, and that each second consists of 75 frames. The corresponding number of sectors is 333,000 or (74 * 60) * 75. With this information, we can get 333000 * 2352 = 783,216,000 bytes, or 746.93 MiB.

Now, in practice, you don't get exactly 333,000 frames, it's more of an estimate. Blank CDs contain data which defines the boundaries of the lead in and out sections. So you can calculate exactly how much effective space the blank media reports as available for use. The lowest I've seen is 73m 49s 60f, and the highest I've seen is 75m 07s 00f. Worst case you get 0.5 mins less than 74, best case, you get 1 minute more. However 333,000 is pretty safe estimate when considering the variability - its what most media try to conform to.

Now, there were 80-minute, 90-minute and 99-minute discs produced. The latter two are non-standard and sometimes had unpredictable results depending on writers. I believe the Orangebook standard introduced 80-minute discs, which work because they take advantage of the fact most CD drives can handle slightly smaller pit/grooves. They physically etched more data into the disc, and squeezed out a mere 4 minutes. I can't say exactly much 80-minute discs vary in normal capacity because there's a hard display limit of 79m 59s 74f. However the lowest is 79m 31s 00f, or 0.5 minutes less than 80. The size for this stated maximum can be calculated as 2352 * ((79 * 60) + 59) * 75 + 74 = 846,543,674 bytes, or 807.49 MiB.

Also, there's a thing called over burning, which works by changing the 'lead-out' boundary to squeeze out extra length. Practically speaking, it's not very reliable, and the range of how much is possible can vary wildly - for example, 74 minutes can overburn anywhere from 76m 14s 73f (+2) to 78m 27s 23f (+4). And I've seen 80-minute CDs go from 81m 18s 05f to 82m 50s 58f. It's highly dependent on both media and writer. 90-min CDs can range from 89m 59s 00f to 93m 17s 36f. And 99-minute CDs can overburn to 102m 10s 02f, or a whopping 1031.24 MiB - that's just over 1 GiB.

So, it's not an easy question. CDs can have varying physical densities, which mean varying capacities. The actual system data can also take up space, but the user cannot write audio data. Not to mention Data CDs have smaller sectors (2048 instead of 2352) to allow error-correction, which is why you get 650.39 MiB for Data and 746.93 MiB for audio on a standard 74-minute CD.--104.247.231.199 (talk) 11:27, 7 December 2022 (UTC)

Heh, you're right. Unfortunately it's hard to talk about capacity when the technicalities of the data format haven't yet been explained. We also must avoid doing original research.

A number is probably mentioned in some literature somewhere, and if we say anything in the article, that's what we should use. But since it goes hand-in-hand with maximum playing time, you can expect that different sources will have different numbers, and that's if they mention a data quantity (instead of just duration) at all.

If we could do original research, we'd just multiply the 4.3218 Mbps rate (for the CIRC-encoded audio data + subcode) by the 82:34 (4954 seconds) playing time of the longest known CD (at least, the one mentioned in the article) and get a result of a little over 2.61 GB. That's how much data is represented by the pits and lands, as seen by the laser. But when you ask about storage capacity, you probably just want to know about how much audio data it holds. That's 4954 seconds of 16-bit (2-byte) 2-channel LPCM at 44.1 KHz, or 4954×(2×2×44100) = 873,885,600 bytes = 833.402 MB. —mjb (talk) 09:14, 23 November 2013 (UTC)

The thing is, the maximum length / capacity of a standard disc IS a known quantity, though there are several ways of judging it. Going by the Redbook standards, you can specify a length of upto 79m 59s 74f, IE one frame short of 80 minutes. The amount of useful audio data you can store in that is 2352 bytes x (((79) x 60 + 59) x 75 + 74) = 2352 x 359,999 = 846,717,648 bytes = 807.49MiB. If you throw in subcode data as well, that's multiplied by 25/24 = 841.13MiB (rounding down as per convention for storage) or exactly 881,997,550 bytes. For CDROM data, it's 2048 x 359,999 = 737,277,952 bytes or 703.12MiB, inclusive of any filestructure data. VideoCD is a bit trickier as it's usually a mixed-mode multisession affair, but if we go with the simplest structure that only has CDXA Mode 2 data and nothing else, that's 2324 x 359,999 = 836,637,676 bytes or 797.87MiB. Thus we have the commonly stated "800MB" or "700MB" figures, corresponding respectively to a rough average of Audio and Video capacity, and useful data capacity once filesystem is subtracted.

"74 minute" discs I believe can technically be specified for anything up to one sector short of 75 minutes (so they're 74m plus a certain number of seconds), or 337,499 sectors. This works out to ~757MiB for audio (~788MiB with subcode), a max of 748MiB for VCD, and ~659MiB for CDROM. However most "74m" *CDRs* I've encountered are a little lower capacity, at least officially (generally they could all be burned out to at least 660MiB), with the highest being 658MiB = about 74m52s, and the lowest 652MiB = about 74m11s. The commonly stated "650MB" would equate to 73m57s (and 746MiB in audio mode; generally just written as "750MB", and rarely "740MB", as all but the stingiest discs offered at least that, and those which didn't weren't far off), so it's essentially a case - the reverse of that with non-overburned 80m examples - that the manufacturer gives you a little more than the advertised recording length, the same as with audio and video tapes, so they can't be accused of selling you short, should e.g. your recorder run a little bit fast for some reason, or a programme slightly overrun. If I've remembered this one wrong and the maximum is in fact 74 minutes dead or one frame less, then that would be 333,000 or 332,999 frames, and you can work out the results for yourself.

Both of those - and whatever you'd get from 63-minute discs, or miniCDs (~22 mins apiece), or the weird formatting of PacketCDs (which reduced the available space to about 530MB) - are just soft limits, however. They're restrictions imposed merely by compliance with the written standard. The actual data structures allow for the definition of a length up to 99m 59s 74f, ie 449,999 frames, hence the longest available, deeply standards noncompliant CDRs being "99" or "100" minute, as that's the greatest length at all specifiable; probably they would otherwise be considered maybe 97 or 98 minute, but take full advantage of the overburn area by default.

Either way, that gives us some absolute hard limits for our recording capacity: Audio is 1009.36MiB (0.985GiB; with subcode, 1051.42MiB or 1.026GiB... potentially a system limited to 1-GiB addressing might therefore only be able to record 438,261 frames, or 97m 23s 36f, assuming the TOC and other out-of-band structures, error correction, etc don't count towards the total), VCD is no more than 997.35MiB, and CDROM Data maxes out at 878.90MiB inclusive of filesystem.

So in summary: around 750MiB, exactly 807.49MiB and exactly 1009.36MiB are the limits for audio (w/o subcode), and around 655MiB, exactly 703.12MiB and exactly 878.90MiB for data (for 74, 80 and 99/100 minute discs), with VCD being somewhere between the two depending on the balance of AV to other data. Depending how exacting the specification for "74 minute" is, we may be able to derive an exact figure for that as well, but certainly producers of CDRs played rather faster and looser with that particular capacity point than they did with 80m (where almost all discs are within a few frames of, and never more than, one frame short of exactly 80 minutes, often using their exact framecount above 79m59s as a type of manufacturer / brand identifier; this however doesn't affect the *maximum*), as the former was more of a recommendation but the latter is capped by the allowable physical tolerances.

All this can be derived from the actual data listed in the article, or at worst with further reference to the Redbook standards and the maximum lengths prescribed by compliance with their average and best-case tolerances (and worst, for 63-min?), so it shouldn't count as at all OR to include them. It's simple arithmetic - maximum prescribed length in frames, multiplied by how much each frame can store (2352 for audio, 2450 inclusive of subcode, 2324 for the AV area of a VCD (menus etc are regular CDROM), and 2048 for CDROM data). It might even actually be already worked out somewhere and directly citeable. If not, even the unit conversion tag-tool may be sufficiently flexible to allow evaluation of the answers from cited raw data. 51.7.16.171 (talk) 13:02, 28 July 2019 (UTC)

SHM-CD

It would be nice if somebody could add a section on this, or remove the redirect link. It's not cool to have a redirect for SHM-CD to this page, and then have this page utterly silent about it.

-TMusgrove. — Preceding unsigned comment added by Tmusgrove (talk • contribs) 20:57, 25 February 2014 (UTC)

Could you elucidate? It's not something I've ever heard of before, so I'm at a loss for being able to add any such information, or even gauge how many people might actually follow such a link. 51.7.16.171 (talk) 12:28, 28 July 2019 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Compact Disc Digital Audio. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added {{dead link}} tag to http://www.audaud.com/article.php?ArticleID=410
• Added archive https://web.archive.org/web/20090822172353/http://www.dvddemystified.com:80/dvdfaq.html to http://www.dvddemystified.com/dvdfaq.html
• Added archive https://web.archive.org/web/20141104160226/http://www.exp-math.uni-essen.de/~immink/pdf/cdstory.htm to http://www.exp-math.uni-essen.de/~immink/pdf/cdstory.htm
• Added archive https://web.archive.org/web/20141104160224/http://www.exp-math.uni-essen.de/%7Eimmink/pdf/beethoven.htm to http://www.exp-math.uni-essen.de/~immink/pdf/beethoven.htm

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:48, 29 November 2016 (UTC)

Storage Capacity and Playing Time

I would suggest removing the two longest CDs in this list. I suspect that they are CD-Rs, and it has long been possible to exceed Redbook standards by overturning with CD burning software. I don't think it's fair to list such CDs in the playing time section, at least not without proof that they are not pressed Cds.

Kirkmc (talk) 10:59, 12 May 2017 (UTC)

It seems fair if they're commercial releases. A lot of smaller publishers have gone over to issuing (otherwise perfectly professional looking) CDRs instead of pressed discs, presumably because of cost concerns around short/limited runs. Whatever you can achieve with a CDR, you can also achieve with a pressed disc - there need not be any distinction. In fact, it's long since been the general practice to produce the pressing master directly from a high quality ("gold") CDR copy... it may well be they used a 90-minute (or slightly less extreme but still over-80-minute) blank to create said master. Or just found one that allowed quite extreme overburning (typically you can't get more than about 81:30 but I've found some that run to 83 ~ 84 minutes) and made sure the pressing plant extended the pressed polycarb layer and its metal film coating far enough out to the very edge of the disc to accomodate that. 51.7.16.171 (talk) 12:26, 28 July 2019 (UTC)

Decca, which includes Deutsche Grammophon within Universal Music, has released several CDs in their "megaboxes" that exceed 86 1/3 minutes. Ref https://www.bach333.com/en/assets/downloads/bach333_sacred-cantatas-1.pdf

Bach 333 (2018) CD 5: 86:33; CD 9: 86:21

Beethoven 2020 (2020) CD18: 86:33; CD21: 86:21

I am currently working through ripping these CDs to disc. If you need more examples, just ping me. Rwlesses (talk) 14:50, 24 January 2020 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 3 external links on Compact Disc Digital Audio. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20120501075730/http://www.ccs.neu.edu/home/bchafy/cdb/info/info.html to http://www.ccs.neu.edu/home/bchafy/cdb/info/info.html
• Corrected formatting/usage for http://www.dvddemystified.com/dvdfaq.html
• Corrected formatting/usage for http://www.exp-math.uni-essen.de/~immink/pdf/beethoven.htm

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 22:31, 26 July 2017 (UTC)

Redirects

Jeh has reverted my bolding of Red Book in the lead. Yes, Red Book is a disambiguation page but, other redirects here include Redbook audio, Red Book Audio, Red Book (audio CD standard), Red Book (CD standard) and so on. There are many articles that link directly here through these redirects and so I believe it is appropriate to bold this term to orient readers who land here from these other articles. ~Kvng (talk) 13:34, 19 March 2018 (UTC)

I disagree. MOS:BOLD allows for use of boldface in only a few situations. ("only for certain usages [...] in the remainder of the article only in a few special cases.") Not a lot of wiggle room there. "Name of a DA page that links here" is simply not among the allowed uses.

Per MOS:BOLD, the purpose of bolding the appearance of a redirected term in the target redirect article is to alert the reader that "yes, this is the right article" even though the article title doesn't match the name they clicked on - to alleviate "astonishment". There is obviously no such issue when following a link from a DA page.

One might say "what does it matter". It matters because uncorrected misuse of BF only leads to more overuse, including e.g. highlighting things that should have been in italics or quote marks (like newly-introduced terms), or highlighting part or model numbers, etc. The result is often a "sea of bold" where the use of BF conveys no useful information whatsoever other than "an editor thought this should be bolded". Jeh (talk) 14:57, 19 March 2018 (UTC)

We have over 100 incoming links through the Red Book (audio CD standard) redirect. I beleive that per your reading, policy would allow me to insert a bold Red Book (audio CD standard) in the lead to reduce astonishment of the presumably many readers coming through that path. Apparently a less clumsy Red Book mention is not allowed instead because that would be unacceptably harmful because it tells the readers that visit via the Red Book disambiguation something they already know. It is possible that you have read the policy correctly. In any case, I don't think this is getting us to where we want to be for our readers. ~Kvng (talk) 17:16, 19 March 2018 (UTC)

MOS is a guideline, not policy, but anyway.. you make a good point, and it does say at the top of MOS that "occasional exceptions may apply". I support your restoring your edit. Jeh (talk) 17:57, 19 March 2018 (UTC)

Linear PCM vs. PCM

Maggyero wants to change instances of linear PCM to PCM. Their justification is, The page "Linear pulse code modulation" does not exist, it redirects to "Pulse code modulation". This is true but it is not a great justification. Linear PCM is identified in bold as a topic and clearly explained in the second paragraph of the PCM lead. The CD uses linear PCM which today is may not be readily confused with other PCM variants but back when the CD was developed other PCM variants such as mu law and a law were more prevalent relative to linear PCM and linear PCM was considered lavish. ~Kvng (talk) 13:48, 4 December 2020 (UTC)

Any cd with 48000Hz

Are there any cd with 48000hz instead of 44100Hz 16 bit pcm AMPLECONCH (talk) 09:15, 23 January 2024 (UTC)

No, these would not be playable in a standard CD player. You can get further with CDROM with 48 kHz WAV or MP3 files. ~Kvng (talk) 13:55, 28 January 2024 (UTC)