Jump to content

Talk:Audio bit depth/Archive 1

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1

I changed the link on the word "sample" in the first paragraph, to point to Sample_(signal). It was pointing to Audio_sample which now redirects to Sound_bite. --Lake44 (talk) 12:44, 1 October 2008 (UTC)

this page has serious basic problems

This page has incomplete, very poorly organized information which, thankfully, is available elsewhere in Wikipedia in better depth and clarity.

One note: With regard to the use of the term "resolution" -- the term is often used informally in the audio world to refer to the word length of the sample format. —Preceding unsigned comment added by Dogmo1001 (talk • contribs) 00:01, 6 January 2009 (UTC)

sentence syntax

it is written "the amount of audio data per second is double that of mono." is that correct syntax? or should that be something like "the amount of audio data per second is double than the one of mono?" Twipley (talk) 22:15, 21 April 2009 (UTC)

Non whole number bit depth

Gentlemen, please mention if non whole number bit depth is possible. E.g., 

32kb/s=BD*24kHz; BD=4/3.

Jidanni (talk) 19:09, 9 June 2008 (UTC)

No, not really. Bit depth is mainly applicable to PCM audio. Formats with a "data rate" in the way that you are describing do not properly have a bit depth. A non whole number bit depth would imply a non whole number of bits, which is silly. Radiodef (talk) 11:02, 22 June 2012 (UTC)

Bit resolution?

It seems like most people seeking information regarding audio bit depth would benefit from also have bit resolution included. Bit resolution and bit depth go hand in hand for the audio world and you can not understand one with out the other. I agree the two articles should be merged. —The preceding unsigned comment was added by Bororecording (talk • contribs) 04:25, 4 December 2006 (UTC)

Hi,
The word resolution doesn't even have a meaning regarding audio.
More bits = more dynamic range, not more "resolution."
This is not a discussion regarding pixels on a screen.
Bit Depth, would be the correct article to discuss all such questions. —The preceding unsigned comment was added by 85.165.33.150 (talk • contribs) 15:51, 4 December 2006 (UTC)
The closest thing to "resolution" in the digital audio world would probably be sampling rate. There is no such thing as "bit resolution". A bit is either a 0 or a 1. There is no greater or lesser resolution available. —The preceding unsigned comment was added by 74.92.147.125 (talk • contribs) 15:29, 14 June 2007 (UTC)
I'm not sure why this discussion is up here at the top of the page, but in any case, bit depth is indeed the resolution of the audio. While true that a higher binary word length simply means that the numbers can go higher, that is not the same thing as the amplitude increasing or decreasing between bit depths. PCM audio describes a graph of a sound wave between some abstract minimum and maximum, and the binary word length of each sample determines how many possible values there are in between (in other words, bit depth is the vertical resolution of the graph). For instance, 8-bit audio isn't "quieter" than 16-bit audio. 8-bit audio is a less detailed graph than 16-bit audio. Radiodef (talk) 11:36, 22 June 2012 (UTC)

Recommendation for dither and lossy transform-type formats

In a course on mastering that I took at Berklee College of Music, it was recommended that dither not be applied when lossy formats, like mp3 and AAC, were the destination. The reason being that dither to combat quantization is really only applicable to PCM because formats like mp3 do not really "quantize" in the same sense, especially if they are floating point. I'd like to add this to the article, but I will try to find a source for this first. Google wasn't initially helpful, so I'll keep digging. This seems relevant to me. Radiodef (talk) 17:11, 13 September 2012 (UTC)

As you've hinted here, it does depend on how the lossy coder is implemented. Most engineers I've talked to agree that there's little to be gained and something potentially lost by dithering 24-bit signals. If your coder takes 16-bit PCM and your source is 24-bit or floating point, you probably want to dither. Even better, you should upgrade your coder.
Refs would be good but, what I'm really saying is that it depends and so probably irresponsible to make a blanket recommendation as you've proposed above. --Kvng (talk) 17:47, 13 September 2012 (UTC)
I've been able to find a few references on the subject, but they are both original research.
http://www.audiorecording.me/dithering-and-sample-rate-conversion-before-mp3-encoding-complete-study.html
WP:OR is research done by WP editors. This is done and published outside WP so not WP:OR. But there are other concerns: WP:PRIMARY, WP:RS.
http://mp3decoders.mp3-tech.org/lsb.html
This is not really hitting the mark. It is testing capabilities of the encoders. Dither is used as part of the procedure but it's not what's being investigated. -—Kvng 17:24, 14 September 2012 (UTC)
Radiodef (talk) 15:45, 14 September 2012 (UTC)
So I am thinking, unless there's a more respectable publication on the subject, leave it be. I also don't remember now where I was thinking about adding the note anyway. If there were a better reference, there are probably other articles it's more relevant to. Radiodef (talk) 17:34, 14 September 2012 (UTC)

Merger proposal

I just stumbled upon Quantization (sound processing). It's barely been edited at all since its creation and apparently it's an artifact of an article split in 2006. Almost all articles on WP link to Quantization (signal processing), and I don't know why quantization should need its own article just for sound. There is honestly not much to say about it that's unique to audio, besides its correlation to audio bit depth. I'd propose to just delete Quantization (sound processing) altogether, but it warrants a section somewhere and there are also many articles that link to it. Radiodef (talk) 04:03, 19 October 2012 (UTC)

And I should also point out that by "merge", I mean trashing almost all of Quantization (sound processing), due to the nature of the content. Radiodef (talk) 04:08, 19 October 2012 (UTC)

I fully agree that Quantization (sound processing) should go away. I recognize three potential destinations for the material: -—Kvng 14:48, 21 October 2012 (UTC)
  1. Quantization (signal processing)
  2. Audio bit depth
  3. Dither#Digital_audio
  4. /dev/nul
And, for the most part, I'd plan on simply turning Quantization (sound processing) in to a redirect. The article is devoid of any citations, the information is largely contained elsewhere on WP and the article is mostly a relic from the 2006 article split (see Talk:Quantization_(sound_processing) and the old revision of Digital sampling). So the question to me is whether to:
  1. Redirect it here and possibly make a new section that summarizes the implications of bit depth and quantization. This makes the most sense to me because the information in both articles is relatively parallel.
  2. Only turn the article in to a redirect to Quantization (signal processing), because that article is comparatively technical and there's not really a place for the information in Quantization (sound processing). I've got no objection to this because, in my opinion, Quantization (sound processing) doesn't need to exist at all, for the reasons I've asserted.
  3. Redirection to Dither#Digital_audio could also work, I suppose, and in fact that section had a main article listing to Quantization (sound processing). (Although I removed the main article link because it's not at all accurate now.)
To me, the decision is really dependent on what articles link to it and what readers are hypothetically expecting to find when they visit the article. Radiodef (talk) 01:34, 23 October 2012 (UTC)
I've examined the links. I think once any useful material has been salvaged to the destinations I suggest above, the article should be redirected to Quantization (signal processing). -—Kvng 14:40, 30 October 2012 (UTC)

 Done Merged Quantization (sound processing) to Audio bit depth and Dither and redirected to Quantization (signal processing). -—Kvng 03:14, 14 January 2013 (UTC)

Floating point bit depths

Float 32 is a common bit depth in professional audio. It would be nice to mention this in the article. The article also doesn't mention the difference between integer bit depths and floating point. C xong (talk) 00:15, 26 May 2010 (UTC)

Done! The article probably needs some cleanup now since it assumes integers all over the place but you are correct that it was needed. Radiodef (talk) 01:15, 11 August 2013 (UTC)

Audio processing section is confusing

I tried to edit this section, but there was some disagreement. The main problem I see here is that the sample precision has little to do with the precision in which audio processing operations are performed, whereas this article seems to think that it does. Generally the first step of processing on a modern system simply loads a sample to a 32 bit floating point register regardless of the input format, making the input sample representation irrelevant. For older software that predates modern floating point processors, operations are generally done on 32 bit ints (as 24 bit CPUs never caught on). Again, the first operation loads a 16/24 bit sample into a 32 bit register, making the representation irrelevant. For fixed point digital signal processors, the actual precision of operations is determined by the width of your accumulator and multiplier and the scaling of values, not the sample format. Furthermore, in fixed point, most operations are typically done at a lower precision than the sample format because of the need to guard against overflow and the performance penalty associated with saturating arithmetic.

I think this section should probably be rewritten to focus on the added dynamic range of 24 bit sample formats, and to explain the distinction between the sample format and the actual precision of an operation (e.g. a MAC). Or if that is too complex, simply state that its now accepted practice to perform DSP at such high precision that quantization error during the operation itself is essentially zero. 18.62.28.10 (talk) 01:08, 15 August 2013 (UTC)

What you said is basically what it says. Higher precision during calculations = less round-off. Upsample was the wrong word but I've corrected that. Statements about accepted practices really need a reference, especially statements that disagree with existing references. Radiodef (talk) 01:40, 15 August 2013 (UTC)
WP:VERIFY, WP:NOR and WP:RELY all cover the need for references. There is just a big difference between a statement like "larger words incur smaller round-off" and a statement like "most DSP systems do ____". The article also does have a section for dynamic range. Radiodef (talk) 02:05, 15 August 2013 (UTC)
Well it sort of says that, as well as some other things that aren't exactly correct. I'm going to go through and fix the weird bits. Let me know what you think. 18.62.28.10 (talk) 02:37, 15 August 2013 (UTC)
Ok i rewrote that section to include a lot more detail on DSP operations, links to signal processors, etc. I think this gives a reader more of a background on how audio processing really works and why they should care about resolution and precision without going into too much math. It still needs more references, but I don't want to google around for them until theres agreement on what needs to be included. I did add one for dither though, which might be useful elsewhere in the article. 18.62.28.10 (talk) 03:20, 15 August 2013 (UTC)
It looks good. I removed the statement about PT11 because my reference actually appears confused about the 64-bit thing. PT11 has moved to 64-bit architecture but only HD uses 64-bit floating point processing. Native is still 32. I can't find a ref for that other than the Avid product page which I don't think is appropriate. The PT11 FAQ covers the architecture switch but doesn't make a mention of the mix bus. It's worth a mention in the article because, prior to 11, HD was one of the few remaining DAWs that still used integers but a quick Google doesn't find anything for it yet. Radiodef (talk) 23:09, 15 August 2013 (UTC)
I reverted most of those changes because they weren't really correct. You changed a number of statements about processing to filtering, which didn't really make sense. You also added a formula for rounding error that is not correct. You can't just add rounding error amplitude. Its a zero mean error! Maybe we should discuss what you think needs changing? — Preceding unsigned comment added by 18.62.28.10 (talk) 01:12, 19 August 2013 (UTC)
The additions that included the formula had supporting citations. Regarding the stuff about IIR filters, Audio bit depth#cite_note-19 ([1]) actually states that it is the filter coefficients that are the need for additional precision. That's not the same thing as using a higher bit depth and the reference needs to support the statement that cites it. Radiodef (talk) 04:08, 19 August 2013 (UTC)
Yeah I added that cite. The problem is that all the additions about IIR didn't really make sense. You can't just grab phrases out of the reference without understanding them. Fractions (or at least rational numbers) can be mapped onto the set of integers. When you do this its called fixed point representation. Referring to an IIR filter with fractional coefficients is nonsense because in fixed point (which is what that reference is talking about) you are representing fractions as integers. The problem here isn't that the numbers are fractional (or not fractional if you choose to think of them that way), its that the filter is recursive which means that any error feeds back. This makes it VERY sensitive to rounding. This seems like a minor point, but the idea is kind of essential to understanding fixed point precision. Since we're having this discussion I kind of get the feeling that you haven't done much fixed point programming? Perhaps this would be a good time to brush up on it? — Preceding unsigned comment added by 18.62.28.10 (talk) 04:16, 19 August 2013 (UTC)
Again, it's not the bit depth of the audio that is the need for extra precision, as per the ref. There needs to be a distinction. This article isn't about all number precision. It's about bit depth. There are other articles besides this one. Radiodef (talk) 04:44, 19 August 2013 (UTC)
There's plenty of nuance to cover but it just needs to stay on topic and relevant to the subject of the article. Radiodef (talk) 04:58, 19 August 2013 (UTC)
The choice of convolution as an example of a process that sensitive to rounding is a bit strange. Generally FIR filters are used because they are very resistant to rounding error. Its actually pretty common to perform convolution at a lower precision than other operations because of its robustness. ARM even provides a lower accuracy multiply instruction thats meant for FIR. Do you mind if I delete that? 18.62.28.10 (talk) 05:24, 19 August 2013 (UTC)
The reference lists convolution so convolution is the example I used. That is what the inline citation after the statement is for: "such as convolution.cite" Radiodef (talk) 05:36, 19 August 2013 (UTC)
Yeah but that reference just uses convolution as an example of a DSP operation that can be performed efficiently on a hardware DSP. It doesn't mention convolution as being particularly sensitive to round off error, or at least not more than anything else (unsurprisingly since its not really that sensitive). 18.62.28.10 (talk) 05:53, 19 August 2013 (UTC)

It says "In performing these types of repetitive DSP calculations, quantization errors from truncation and rounding can accumulate over time, degrading the quality of the DSP algorithmic result." Radiodef (talk) 06:29, 19 August 2013 (UTC)

"High levels of precision are necessary for algorithms that involve repeated processing, such as convolution." Rounding errors accumulate for all types of operations. Where do you get that "high levels of precision are necessary" for convolution specifically? FWIW since audio signals are zero mean, generally M*N convolution scales with something like sqrt(N), which is pretty close to the best case scenario. — Preceding unsigned comment added by 18.62.28.10 (talk) 07:34, 19 August 2013 (UTC)
It totally depends on what is considered a high level of precision. Maybe that's 64 bits or maybe it's anything bigger than 16. "High levels of precision" is a highly subjective statement. I did not add that to the article. Convolution is an example of repeated processing that benefits from higher precision. Basically all processing benefits from higher precision. It's an example and what I found a reference for. I'm not here to keep reiterating this stuff. Please just read the help docs. Radiodef (talk) 09:11, 19 August 2013 (UTC)

Dynamic range

I've expunged much of the dynamic range discussion. This was uncited and wrong or misleading. There is a direct connection between resolution and signal-to-noise ratio. Limited resolution does not fundamentally limit dynamic range so long as the sample rate is not correlated to the signal or the signal is properly dithered. --Kvng (talk) 15:15, 26 July 2011 (UTC)

Thanks for the trim job. Note that there is a dynamic range loss involved in filtering and in conversion to and from analog. For instance, commonly observed 16/44 audio dynamic range is about 90 dB even though the theoretical DR is 96, or 98 dB for a pure sine wave. Binksternet (talk) 16:00, 26 July 2011 (UTC)
It looks like you're actually talking about S/N. Many (including professionals/scientists) don't make a distinction between the two. For those who split hairs, dynamic range appreciates the fact that a signal can be detected below the noise floor. S/N does not. The noise floor for a properly dithered 16-bit recording should indeed be higher than -96 dB. If the source material and recording equipment supports it (generally it won't), the dynamic range of such a recording can be greater than 96 dB. --Kvng (talk) 17:58, 26 July 2011 (UTC)
Aha! Thanks. Binksternet (talk) 18:20, 26 July 2011 (UTC)
I assume you added this: "With the proper application of dither, digital systems can reproduce signals with levels lower than their resolution would normally allow.[7] Therefore there is not a direct connection between bit depth and dynamic range."
The is not totally correct. It is more accurate to say that dithering trades bandwidth for dynamic range. However, since in CD audio the bandwidth is fixed, and isn't low-pass filtered in the player (to get rid of the high frequency noise dithering introduces), it would be basically wrong to use dithering. For a fixed bandwidth there *is* a direct connection between bit depth and dynamic range. Someone (me?) should fix this section. Also note that PWM signals (like 1-bit DACs) are an extreme example of this. They only work because the signal is low-pass filtered before it is heard (the low pass filtering may be done by the ear itself if the dithering is high frequency enough that you can't hear it). 86.132.24.70 (talk) 11:22, 30 July 2012 (UTC)
Dithering trades signal-to-noise (raises the noise floor) for dynamic range. Bandwidth perhaps comes in to play when noise shaping is included. --Kvng (talk) 17:13, 2 August 2012 (UTC)
You can choose the distribution of noise but it is always going to be limited by the finite bandwidth of digital audio. However you can't increase dynamic range within a band by *only* adding noise to that band. You have to add it elsewhere, and for there to be an "elsewhere" you need some spare bandwidth. I will revert the changes and try to clarify this point with some references.86.159.109.30 (talk) 11:30, 3 August 2012 (UTC)
While true that dither can allow for audio that is lower than the dynamic range would normally be able to store, I find the statement that "Therefore there is not a direct connection between bit depth and dynamic range." to be vague and a little specious. Without dither, the signal eventually becomes mangled in to hard quantization, and the difference with dither is that the signal instead fades in to noise. This lets the signal "show through" a little further, but eventually it does just turn in to noise. There is a direct connection, but dither sounds better. I am going to change the wording to reflect this. Radiodef (talk) 17:01, 13 September 2012 (UTC)
I've removed the whole Therefore... clause. Your change introduced an open-ended comparison and the whole thing smells of original research with or without your revision. Best to leave it just as far as the ref takes us and no further. --Kvng (talk) 18:03, 13 September 2012 (UTC)
Fine with me. Radiodef (talk) 15:35, 14 September 2012 (UTC)

I gutted this section again, removing the following examples:


Most of these examples are just verbosely expanding on the SNR info and resolution table provided in the quantiation section, earlier in the article. I thought maybe we could reformulate the info into a table or introduce dynamic range at the same time as quantization, but now I'm thinking it's better just to remove it. So I replaced all of it with a simpler statement saying that dynamic range (without dither, oversampling or noise shaping) correlates to the quantization noise, and I provided one 16-bit example.

I do understand the desire to give examples of the effect of dither on dynamic range at various bit depths, but I'm not convinced this is necessary or practical. There are different types of dither, yet the examples we had given ("1-bit", "-90 dB") seem to assume certain parameters the reader isn't going to understand.

The cassette example is in a similar boat. The dynamic range and noise level of audio cassette actually ranges from 6-bit to 9-bit equivalent, according to the 2nd xiph.org video, but I'd rather avoid making any comparison at all unless we can explain the nuances better. A lot of readers aren't even going to know what a cassette sounds like anyway. Might as well talk about vinyl if we talk about cassette!

Likewise, DV and NICAM are already covered under Applications; mentioning them again here seems to only be intended to emphasize the adequacy of 16-bit systems for practical listening without damaging one's hearing. I agree with the sentiment, but would rather make that argument via citations of external sources. —mjb (talk) 19:47, 19 August 2013 (UTC)

Floating point is complicated

TMI or not enough? Radiodef (talk) 01:55, 12 August 2013 (UTC)

Its not super important, but not bad either and its something that people tend to not be familiar with. I'd leave it. One concern I have reading the entire page is that there is a lot of talk about resolution. From a practical point of view resolution is almost irrelevant to anyone but hardware engineers, its the SNR and effective number of bits that most people actually care about. IMO it would be nice to make it more clear that resolution is just bounding the ENOB and SNR, nothing more. 18.62.28.10 (talk) 04:36, 13 August 2013 (UTC)
Well those two topics do have their own pages but you're right about their relevance to the article and there are some other kinds of general problems like this. Another problem with integers and audio is of course there are really only a couple of scenarios where you are actually using all the bits before quantizing. SNR also has a brief section on floating point but it doesn't explain how they derived the two short formulas and in practice they are fundamentally wrong since IEEE doesn't use the full range of values. I haven't been able to find a reference yet for the explanation of the correct floating point SNR math, just conceptual statements. Radiodef (talk) 21:21, 13 August 2013 (UTC)
If I understand correctly, that article is just stating that the quantization error per sample is equal to that of an integer the size of the mantissa. This is very nearly correct since I believe the only difference between mantissa and a normal int is that IEEE754 doesn't use twos complement so +/-0 will result in a single code being duplicated. I think though this will only hold if your dynamic range is comparable or smaller your SNR, or else the RMS quantization error could be very large if you have a few very high amplitude samples.
Regarding resolution, I think its important to make clear that dynamic range and SNR are the true quantities of interest, whereas resolution is not really all that physically meaningful unless you're trying to write the A/D driver. For example, I can represent a measurement with 60dB SNR with 10 bit samples, 8 bit samples with 16x oversampling, or 16 bit samples. All of these representations are equivalent and interconvertible, but the first has lower resolution than the second, and the third has higher resolution than the second. 18.62.28.10 (talk) 06:35, 14 August 2013 (UTC)
It's a bit more than that. IEEE actually reduces the minimum and maximum range to reserve certain values for special numbers like infinity (all 1 in the exponent) and zero which can't actually be normally represented in IEEE. The problem with your example as it pertains to the article is that if you have a situation where the context of the signal isn't dependent on bit depth then I'm not sure it belongs here. Dynamic range and Signal-to-noise ratio have their own articles. Effective number of bits would be a worthwhile mention since it does relate conceptually but to the greater extent Audio bit depth is just a summary of how bit depth relates to audio. Adding topical caveats (like "this matters, but this other thing matters more") is somewhat perilous because inevitably there is somebody that will read it and disagree. Radiodef (talk) 21:04, 14 August 2013 (UTC)
If you look again at that formula for FP numbers, it assumes that the exponent contributes nothing to the SNR. So while some exponent values are invalid, it doesn't matter in this case because you're assuming that the exponent isn't contributing anything anyway. Regarding SNR, I'm not sure I understand. Can you give an example of the "context of a signal"? I'm not sure what this means. 18.62.28.10 (talk) 00:44, 15 August 2013 (UTC)
In your example, you say you can represent a measurement in so many different bit depths and they are equivalent. If the bit depth doesn't matter to your measurement then I don't see how it goes in an article that's just about bit depth. I don't think this article is the place for scenarios where the number of bits doesn't matter, the article is about how the number of bits does matter. There are other articles like Audio system measurements and Audio noise measurement that cover these kinds of things more generally. Radiodef (talk) 01:25, 15 August 2013 (UTC)
To be clear, you can represent any measurement using an arbitrary resolution with arbitrarily high fidelity. Not just my measurement, but all measurements. For example, DSD does > CD quality audio with just 1 bit worth of resolution! Even more extreme examples are possible. If your article requires that resolution alone determine something its going to be a blank page. We could structure this article just just literally state that resolution in integer systems is dynamic range / quantization levels, but thats probably not very helpful to the average person interested in audio. Instead I think it would be more useful to relate audio bit depth and quantization in terms of SNR and dynamic range (and to some extent it already is), which I suspect are the true quantities of interest in audio, not the differential voltage produced per sample period. 18.62.28.10 (talk) 02:35, 15 August 2013 (UTC)
I added a section on oversampling. Probably we should add one for noise shaping as well. Then we can relate PCM bit depth to how SACD works. 18.62.28.10 (talk) 01:32, 19 August 2013 (UTC)
I've reorganized the article sections to reflect all the additions. I also left a welcome message on the talk page for your IP with some more general comments.Radiodef (talk) 03:40, 19 August 2013 (UTC)
I'm not even sure how to check that, maybe we can just talk here? FWIW, I don't think putting oversampling in with processing makes sense. Oversampling is a means of representing an audio format. CD audio is 16 bit, 1x oversampled. DSD is 1 bit, 64x oversampled. I was thinking of organizing it with integer -> floating point -> oversampling -> noise shaping -> sigma-delta -> DSD. Or maybe combine sigma delta and noise shaping? Either way its not really processing, its just something about how you store your signal. — Preceding unsigned comment added by 18.62.28.10 (talk) 03:46, 19 August 2013 (UTC)
Oh i can just click after that post and get to it. Anyway, my concern here isn't citations just yet, its fixing this article. A lot of it is misleading or just plain weird. We can find references on google in no time once we've corrected all the problems with the text. Towards that end I wish you would be a little more careful with your edits. Things like your statement about fractions and precision are ... odd. Or the unusual formula for rounding error which I do not know where you found. Things like this need to be thought about a little more carefully before you add them. 18.62.28.10 (talk) 03:59, 19 August 2013 (UTC)

References do matter. The formula is from the reference. I extrapolated the formula from numbers they gave, but it's in the reference. You can think the reference is wrong, but it's in there.

This is probably an intermediate structure for the article but it's better than having all of it crowding under the same heading. Oversampling could be put under quantization if that makes more sense to you. Radiodef (talk) 04:22, 19 August 2013 (UTC)

I'm sure the reference is correct, nonetheless what was added to the article is not correct. I'm just saying, please be more careful when editing things. Its better to add nothing than to add something incorrect, so if you aren't sure, ask. I'll take a look at layout.
Look, I don't know what to say. You are removing information that is correct and cited and also adding information that is not cited. Please stop doing that. Please read the help docs that I linked you to as they are guidelines that all contributors are obliged to abide by. If you don't think a cited statement is supported by the reference, at least go read the reference. Radiodef (talk) 05:30, 19 August 2013 (UTC)
Well, if I were you, I'd begin by explaining what I thought I knew so that its possible for other people to help me understand more completely what I was missing. No sense doing much else, since its hard to help you if no one knows what it is you actually think. 18.62.28.10 (talk) 05:57, 19 August 2013 (UTC)
You are missing the point. Please stop removing cited information and adding uncited information. It's OK to be new and not know there are guidelines for this stuff but that's not the case anymore. Wikipedia policy is to assume good faith and I am doing that but you need to have sources when you make major additions. Adding lots of uncited stuff to articles doesn't make them better. It just makes them more uncited.
Regarding oversampling, noise shaping and delta-sigma, these are not really on the subject of the article. Delta-sigma does not have a proper bit depth and noise shaping like that has very little to do with bit depth. If you want to contribute to those topics, those topics have articles. If you want to contribute to those articles, please follow the guidelines. If you can't be bothered to follow the guidelines then it begins to be disruptive editing. Radiodef (talk) 07:16, 19 August 2013 (UTC)
I'm not missing the point, I only removed incorrect statements. Its great that you cited something, but if its not true and the citation doesn't support the statement, its important that it be removed. And anyway, unless I'm misremembering, I think I just reverted the edits that added incorrect statements/references. AFAIK this is proper?
Regarding Delta-sigma, it does have a bit depth. Delta-sigma converters come in 1, 2, 3 bit ... versions. Take a look at the Delta-sigma wiki page. Noise shaping is quite important, since along with bit depth and oversampling, it determines the resolution in PCM. — Preceding unsigned comment added by 18.62.28.10 (talk) 07:39, 19 August 2013 (UTC)
The statements you removed were correct and supported by the references. If anything, you disagreed with the wording and that's it. Delta-sigma is not PCM and the Delta-sigma article doesn't use bit depth anywhere in the article. I am also a bit confused now because you changed this article to say that Super Audio CD does not have a bit depth and Super Audio CD is Delta-sigma. I am not really sure what you think bit depth is. According to this article, bit depth is the number of bits in a PCM sample. If you think bit depth should include things that aren't PCM then you should start a discussion topic and wait awhile for people to weigh in as that is a very major change to the entire article. Noise shaping is an important topic but it has an article that's about it. There's not a need to add a little blurb about everything related when all those things have entire articles dedicated to them, especially when those articles really need major improvements themselves. Radiodef (talk) 09:45, 19 August 2013 (UTC)
Thinking about your point more, perhaps the problem is that this article is mis-named? I see that Resolution_(audio) redirects to audio bit depth, but perhaps the reverse should be true? If resolution is the true quantity perhaps it should be the article title. Alternatively, since a signal with a given oversampling ratio can be converted to a non-oversampled signal with a greater bit depth, perhaps the concept of bit depth should be elaborated upon from how we currently define it? — Preceding unsigned comment added by 18.62.28.10 (talk) 07:55, 19 August 2013 (UTC)
Actually rereading all the edits, I think I misread the original formula for rounding error. Looking at it, it expressed noise power in terms of 2^N operations for a given power. I said no this is wrong, and changed it to say that noise scales with sqrt(N). In fact these are the same idea just expressed in a different sense. Or at least I think so. Do you want to try and take a look at how to combine what we both wrote into the least confusing possible version? I can take a look at it in the morning. 18.62.28.10 (talk) 08:06, 19 August 2013 (UTC)
Bit depth is the right term as it's encountered practically everywhere in sound recording. This isn't really a DSP article. It's not categorized as one and it's not in the scope of either of the projects that usually cover DSP. Also look at what links here. Radiodef (talk) 09:24, 19 August 2013 (UTC)
And 2^N operations would assume the error was building additively at each operation, i.e. not a mean of 0. It's the kind of thing that's hard to simplify and I am really not sure a lengthy explanation is necessary. I've always been questioning whether there really should be much of a section on processing the audio at all because once you are doing math there is not really a bit depth anymore. Just precision of the numbers you are using and that's not really the same thing to me. Radiodef (talk) 10:09, 19 August 2013 (UTC)
TMI. We should trust readers to visit IEEE floating point for this level of detail. I have moved some of your content there. ~KvnG 03:45, 25 August 2013 (UTC)
OK, that's fine. Radiodef (talk) 06:11, 25 August 2013 (UTC)

Applications and Bit rate sections

Interested in comments:

  • Applications could be completely replaced by a table.
  • Bit rate could be removed altogether and placed in the see also.

Radiodef (talk) 03:54, 19 August 2013 (UTC)

Sounds good to me. 18.62.28.10 (talk) 04:01, 19 August 2013 (UTC)
Yeah, I was surprised to see separate sections on bit rate and file size, but bit depth does affect those things, so I don't see the harm in mentioning them. Maybe put them under a single heading, though?
As for applications becoming a table, this reminds me that I've been smacked down in other articles for replacing prose with lists. Apparently there's a contingent of editors who feel very strongly about using prose when the content (e.g. each item in the list) takes the form of sentences. Lists and tables, they feel, should only contain more granular data, like nouns, numbers, etc. Maybe it's not worth worrying about, but I'd hate to see someone come along and undo it all. —mjb (talk) 12:31, 19 August 2013 (UTC)
I guess my question is whether the prose is really necessary. There's basically two bits that aren't just listing:
"Digital telephony frequently uses 8-bit quantization. That is, values of the analogue waveform are rounded to the closest of 256 distinct voltage values represented by an 8-bit binary number. This crude quantization introduces substantial quantization noise into the signal, but the result is still more than adequate for human speech. Mobile phones, however, use more complex schemes such as linear predictive coding."
and
"The CD-DA format used on compact discs uses a 16-bit integer PCM. This is far better than telephone quantization, but CD audio without dither can have noticeable distortion and quantization noise when low audio levels are played with sufficient amplification."
The section on digital phones would be harder to reduce to a list because it's a generalization but I don't like the generalization and think it would be more informative to have something like "Digital phones such as ___, ___ and ___". The comments about CDs are obvious. There's also that very long and speculative (also perhaps outdated) sentence that I flagged as needing a citation and I'm inclined to remove it as well. 16-bit is not hi-fi anymore, CDs are declining and some stores even sell music in higher formats. Bandcamp sells FLAC and you can upload anything you want to them.
So I question whether the prose is really necessary. As far as bit rate, I've reduced the information in that section to the point where it's all to the point. PCM/LPCM is not usually described as having a bit rate but sometimes it is and the formula listed there is not anywhere else on WP that I know of. The stuff about file size is also not anywhere else on WP that I know of. Both of the formulas seem obvious but not to everybody I'm sure. Radiodef (talk) 06:49, 25 August 2013 (UTC)
I personally have no objection to ditching the prose for the reasons you state. I say just go ahead and do it.
Regarding bit rate, I'm guessing the intent was to help readers understand the difference between bit depth and bit rate (and just that there is a difference). I don't see what we have as being crucial; if I were rewriting the article from scratch, I'd go with the See Also. But someone thought it was important enough to mention. Maybe look through the history and see who, and if they're still around, invite them to the discussion? —mjb (talk) 07:06, 25 August 2013 (UTC)
The bit rate section has been there since nearly the beginning of the article [[2]], the user that created the article and subsequent sections hasn't been on WP since 2008. And you're correct, the early revisions are clear that it was added to make the distinction. Radiodef (talk) 02:10, 26 August 2013 (UTC)
I'm working on a table right now in my sandbox: [3]. Radiodef (talk) 07:41, 26 August 2013 (UTC)
I went ahead and moved it over as I ran out of solid examples to add. Radiodef (talk) 09:57, 26 August 2013 (UTC)
I think the reason text is preferred over lists or tables is because it gives you the opportunity to explain the significance of the information being presented. Tables are appropriate for things like Comparison of digital audio editors. I don't think what you've done here has improved the article because you've removed some background information, you've added information that doesn't directly pertain to the topic and the table documents three different categories of things with the only clue of that being subtle table formatting. ~KvnG 14:31, 30 August 2013 (UTC)
The bit rate material should probably be incorporated into the Bit rate article. I don't see a good reason for repeating that here - that's what hyperlinks are for. ~KvnG 14:31, 30 August 2013 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Audio_bit_depth/Archive_1&oldid=935848855"