Protections against faulty music pressings (Liz?)

Modern digital data formats do tend to include error-detection-and-correction codes as a additional bits tacked onto every word of the signal or check data tacked onto longer chunks of raw data.

The digital hardware needed to exploit this used to be expensive and old formats (like Compact Disks) didn't bother.

My reference on the subject - John Watkison's "The Art of Digital Audio" ISBN 0-240-51270-7 - dates from 1988, and does go into the techniques used back then. there were quite s few of them.

The Compact Disc format includes substantial error detection and correction, so the CD format very much DOES bother. When the error rate is too high to be corrected the output is muted.

Compressed formats like MP3 are inherently ac coupled due to the coding scheme which throws away anything that is deemed to be inaudible including dc. On the other hand I expect that FLAC would propagate dc if it is present in the original recording. (I haven't actually checked.)

The public telephone network when using A-law or mu-law coding is mostly dc coupled. The codecs at each end are supposed to remove dc, but not all do. For example, the standard rate GSM codec has an error in its high-pass filter coefficients which means that it only attenuates dc by a few dB. This was fixed in the advanced multi-rate codec. There are ways for dc to get into the phone network. For example, using mu-law silence in an A-law system does this. This causes severe problems for echo cancelers which sometimes interpret dc as a valid audio signal. I came across this problem in the wild so it is not hypothetical. John

But the error coding and implementation for THAT physical medium were designed with the PHYSICAL characteristics of the medium in mind. E.g., scratches have to obey certain physical properties. They are typically "few" rather than plentiful.

The very first CD I purchased was "defective" -- the music was recognizable but nowhere near the alleged quality of a digital medium; the guy at the store was stunned to hear it's playback (he had assumed the format was incapable of such faults).

So, the player (mine and his) obviously has no "memory" of the error rate history and just keeps trying to produce audio. Even if the result ends up below the quality one would expect from a 45 that had been "sandpapered"!

This doesn't seem like a good strategy for reproducing streaming content; the types of "errors" are categorically different (e.g., if the media tank can't keep up with the data rate then there are periods where there is NO data available; if the data arrives late, should it be played with an intervening period of silence/dropout? Or, discarded to maintain the intended time sync)

I am using FLAC as there is no real advantage to using a compressed format; storage is cheap (as is network bandwidth).

But, there is no guarantee that FLAC hasn't been corrupted. Should a player "look" at the content to determine if it makes sense as a music signal?

If the data stream sees repeated errors/dropouts/underruns, should it continue trying to reproduce what it can -- or just give up and coerce the listener to doing something about it?

I was hoping looking at how (hardware) media players handled errors might give a "philosophical insight" as to what was considered a reasonable strategy (despite the fact that they are considerably more resource constrained).

E.g., with a software *protocol*, one could "read ahead" and check the integrity of the "upcoming signal" instead of just waiting for it to be emitted. You could (for stored content) actually pull the entire piece off the storage medium and perform an integrity check on it to ensure it is intact, in its entirety (there are no "block level" error codings for things like FLAC so the best you could resort to is "did the medium throw any read errors?")

With *live* content (e.g., OTA broadcasts), you'd have to chop the content into smaller chunks, at the source, and tag them with an ECC that you could then validate at the far end. A chunk that failed its ECC could be blanked (what if every other chunk failed thusly? Do you stick to this naive strategy??)

For music (FLAC), you could AC couple the signal in the analog output stage.

But, that doesn't prevent abuses. *Should* you pass a 20KHz square wave having maximal magnitude?? Just because it was "in the digital signal"?

Similarly, if operating in (computational) overload, does shedding things like tone controls make sense (preserving the content albeit colored differently)? Or, is such signal conditioning to be considered effectively part of the original content so, if not reproducible, should be treated as an error in the source?

No expert, but I believe CDs use Reed-Solomon error detection and correction. It works perfectly up to some number of errors, then goes to Helena Handbasket and not gently. However, RS encoding is appended to the data (music) and the data itself is not altered.

I would conjecture that if the RS breaks down some players may not mute but just use the data as is.

Oops. Sorry about that.

My reference on the subject - John Watkison's "The Art of Digital Audio" ISBN 0-240-51270-7 - dates from 1988, and does go into the techniques used back then. There were quite a few of them.

I thought I remembered how the compact disk format worked from the discussions I'd read when it was first introduced, but I'd never bothered to read John Watkinson's specific comments about the format. My bad.

He does have a whole chapter on the subject, and the system is remarkably complicated. It does include error detection and correction (up to a point), but also a lot of interleaving to turn burst errors into random errors. I might have tried to read the chapter at some point, but it would have been heavy going, and I didn't actually need to know.

They use cross-interleaved RS which (up to an extent) allows them to recover corrupted data and synthesize some suitable replacement. But, this comes at a pretty high cost (like 35% burden).

Note that formats like FLAC don't augment the data with such redundancy. So, you have to rely on the storage medium to preserve its integrity and signal "read errors", if anything.

What's frustrating is there's no easy way to make a defective medium to see how the player responds! Neither in terms of forcing errors

For a software player, I can poke around inside a file and deliberately "distort" the audio data. But, that doesn't tell me what would happen if the player couldn't *get* the data (e.g., in a timely fashion).

This leaves me having to rationalize <whatever> approach I adopt instead of relying on what (presumable) "experts" had concluded.

The digital word length and DAC swing limit peak amplitude and speaker/ear damage.

It's amusing to see war movies where sonar operators are deafened by their headphones. Tubes saturated too.

Tone arm?

Digital scratches?

CDs wouldn't work without serious digital error correction.

Probably the guys who mastered the CD were tone-deaf dopes.

More likely there was insufficient S.N ratio in the analogue section of the reading head due to some sort of chemical fault affecting the reflectivity of the disc.

Overloaded valve circuits degrade gracefully - overloaded transistor circuit degrade disgracefully.

If I distrusted the storage medium, I could artificially dice the data into suitably sized chunks and impose my own ECC. Ditto for the transport layer.

But, I don't think that is necessary beyond the data "failing to appear" (in a timely fashion) or having been corrupted prior to storage/retrieval/transport.

I.e., in much the same way that I can deliberately corrupt the contents of a file, who's to say these haven't been corrupted prior to my acquisition? (bug in the ripper?)

I think CD has some means to prevent bit errors blowing your speaker cone out.

The first CD player I bought worked fine, until CD-R came along. Although it could play them, it was like listening to a very badly scratched LP.

:-)

But, is that a safeguard in the player or in the data encoding?

As I said elsewhere, it is hard to create a sample medium to TEST these ideas.

Data errors in the various media are quite different. A solution that works for one, is not necessarily useful for all methods of storage, transport, media, etc. This might offer some clues on how it's done in CD's and DVD's.

"Kees Immink: The Man Who Put Compact Discs on Track"

My CD/DVD player does not have a tone arm. Similarly, my vinyl record player is not digital. It's possible to answer your question, but only if you limit it to a specific media type.

Yep. DC is a problem:

"Eight-to-fourteen modulation"

"EFM requires three merging bits between adjacent fourteen-bit codewords. Although they are not needed for decoding, they ensure that consecutive codewords can be concatenated without violating the specified minimum and maximum runlength constraint. They are also selected to maintain DC balance of the encoded sequence. Thus, in the final analysis, seventeen bits of disc space are needed to encode eight bits of data."

Yes. It's easier to remove encode/decode errors examining the data for anomalies.

Yes. Preprocessing with digital is much easier and better than post processing the analog audio.

Yes, but to a point. It's smart enough to mitigate most mechanical defects on the media. However, there is (probably) a limit as to how many sequential errors can be detected and corrected.

Of course. Any system can be broken by feeding it either too much data, or too little data. Some types of errors are easy to correct. Other are a lost cause:

"Guidelines on the Production and Preservation of Digital Audio Objects (web edition). 8.1.9 Errors, Life Expectancy and Testing and Analysis"

Because of error correction, the media is effectively defect free. "Giving up" is a usable solution as long as the errors are within acceptable limits. Try it yourself. Scratch a CDROM once, and it plays normally. Scratch it about 25 times, and you'll experience problems.

Instead of scratches, streaming audio has all the problems produced by data transmission errors. As I mentioned, different media types are handled differently.

Probably in the player.

I'm sure you're right but it should theoretically be possible.

I searched this document for the term 'Reed' and it wasn't found.

Compact Discs (CDs) use a powerful error-correction scheme called CIRC (Cross-Interleaved Reed-Solomon Coding) to fix both isolated random errors and large burst scratches on the disc surface.How CIRC Works on Audio CDsInner Code (C1): Processes a shortened RS(32, 28) Reed-Solomon code adding 4 parity bytes to 28 data bytes, acting primarily as a fast single-error corrector and erasure flagger.Interleaving: A multi-way convolutional delay line scrambles and spreads data bytes between the inner and outer encoders so that a physical scratch affecting consecutive data gets broken apart.Outer Code (C2): Processes an RS(28,

Reed-Solomon codes are an example of bitvector codes. Reed-Solomon has been optimized to have the greatest differences in accepted codes that it generally can.

Also, the bitvector words are written around and round the CD, in order that a given scratch will impose its will on the fewest closely grouped words.

In a Reed-Solomon RS(32, 28) code, the "greatest difference" refers to its minimum distance (\[d_{min}\]), which is exactly 5. Because Reed-Solomon codes are Maximum Distance Separable (MDS), they achieve the maximum possible mathematical spacing between any two valid codewords.

But how the "eventual output" is handled is the issue. Presumably, people in "that" industry will have given careful consideration as to how "data loss" should be handled in a continuous stream of audio.

The new ones have them. They can also play BOTH SIDES of the CD!

The point is that the stylus is effectively directly tied to the speaker cone with only crude constraints as to that "transfer function".

So, there is no restriction on the actual waveform that can be encoded in a CD. The question then is how far the player goes to constrain how that is reproduced.

The developers had to have considered the possibility that errors might not be RARE, isolated events.

If I encounter an ECC error, I correct it and move on -- a *tiny* performance hit. If I encounter them every 10th access, I can similarly "move on". But, likely should consider what underlying issue is manifesting in this manner.

Yet I have at least one known example of a medium that was so obviously defective that a casual observer could notice it.

This assumes there are likely other errors that aren't as obvious. But, that doesn't make the medium "defect free".

Optical media are designed to tolerate scratches. Because of their physical form, scratches are the most likely sorts of errors they would encounter.

Placement of the data (and ECC) on the medium can exploit this spatial relationship to minimize the impact of such flaws.

A POTS phone conversation, on the other hand, may encounter burst (analog) errors from which no recovery is possible -- beyond "Could you repeat that, please?"

That still ignores how catastrophic errors are handled. And, the rationale for such.

The *policy* that one adopts should be a reflection on what the "data consumer" is most likely willing to tolerate.

In the days of analog TV, you could tolerate poor reception as the BASIC image was still decipherable amid the noise. With DTV, its as if you're just seeing isolated snipets of the material being presented -- though those snipets are very well defined, visually!

That would make sense. But, would still need to be quantified.

I can create an anomaly in the "encoded signal" but still wouldn't know the extent of which would trigger any sort of "recovery mechanism". E.g., if I zero out a few samples, does that just become an imperceptible click/pop? Likewise, if I inject several 0xFFFF, would I be able to aurally identify them in the audio stream?

At what point do I have to decide to take alternative LISTENING measures?

If the player squelches the output to hide an anomaly. Then, unsquelches and squelches the NEXT anomaly a fraction of a second later (etc), I suspect the listener would quickly become annoyed. Would the player's designers assume the listener should be the ultimate "handler" for such a condition? Or, would they take measures (to protect the perceived value of their technology) to avoid such an annoying presentation?