mix-paste, mix-paste invert

I created two mono 32 bit files in CE2K (32 bit 16.8 float (type 1 - 32 bit) ) with Generate/Tones, one the Bell preset, the other the Chord preset, but with each preset modified by pulling down the dB Volume slider to -24dB.

Next I Mix-Pasted them together. Statistics for this mixture are
   Mono
Min Sample Value:   -3835.67
Max Sample Value:   3778.33
Peak Amplitude:   -18.63 dB
Possibly Clipped:   0
DC Offset:   0
Minimum RMS Power:   -35.4 dB
Maximum RMS Power:   -23.83 dB
Average RMS Power:   -28.41 dB
Total RMS Power:   -27.94 dB

Then I Mix-Paste Inverted the first component file into the mixture, then the second file, cancelling out both components. Statistics for this final result are
   Mono
Min Sample Value:   0
Max Sample Value:   0
Peak Amplitude:   -168.58 dB
Possibly Clipped:   0
DC Offset:   0
Minimum RMS Power:   -187.66 dB
Maximum RMS Power:   -174.63 dB
Average RMS Power:   -179.35 dB
Total RMS Power:   -178.77 dB
This can be viewed in Spectral view and the Frequency Analysis graph by setting the resolution higher than default (i.e. 200dB).

Even if 32 bit float there can be quantization errors. I assumed the low level noise I ended up with is just that. Another person, working in CEPro 2.1 says he gets complete cancellation, digital zeros. Does this indicate some program error in CE2K?

Somehow I wouldn't be exactly alarmed by a noise of -168dB peak.

I don't want to alienate people, but why do I get so many “don’t worry about it” replies when I want to know something factual? Is there something in the way I write that comes across as complaining rather than simply asking, or is my writing simply hard to read?

I think in this case it's curious as to why someone would even care about this.  From my perspective, it seems trivial, like asking a minute operational question about Windows 95.  The program has been rewritten and upgraded so many times since that even if it were a programming error that the point is now moot, unless this particular error has tracked its way through all the different versions (which I doubt, but I could be wrong). 

I can't speak for any other person that responds to this or any other question you post on this forum. 

... or is my writing simply hard to read?

Most people's intelligence indicates to them that if somebody posts a seemingly ridiculous/pointless question, then there's something else to it other than just being annoying - like it's a complaint, or something. And when you write, in this context:

Does this indicate some program error in CE2K?

Then yes, a lot of people who didn't realise how you behave would regard this as, if not as an actual one, at least a precursor to a complaint, I'd say.

But since I realise that you are just being annoying, I'll indicate where the probable error is - although I would have thought that it was pretty easy to work out, all things considered. Here's a clue:

Min Sample Value:   0
Max Sample Value:   0

Total RMS Power:   -178.77 dB

It's probably just the stats module. Or if you can see a noise display in frequency analysis, then perhaps that's screwed. Whatever it is, you'd better stop using CE2000 immediately - this could be detrimental to all of our health. I'd recommend an immediate upgrade to a version that reports the result as being no power at all, rather than a random value that you simply couldn't hear.

Dither on in one program, and not the other?

Paul

I don’t believe dither is introduced in any case involving only floating point format data.

What I’m interested in is quantization error, when does it happen and when is there none? Not because of its effect on any audio project I do, but because I want to be able to think about it correctly. The basic answer to the first post is one of the two

There is quantization error when mixing two signals, so there should be some remainder.
or
The levels on those two files are too low for there to be any error from mixing them, therefore there is a program problem.

I realize the responses, such as they were, indicate the second answer is most likely the correct one, although that hasn’t been addressed directly. If it is the case that there won’t be any quantization error in this case, how can I know when there will be? If the two files I mix are higher level, and their sum is greater than 0dB, I get a similar result, just a little higher noise level. However, somewhere along the line of increasingly higher level inputs there would be real quantization errors. This is surely a strictly mathematical problem, but I’m not sure about the math here.

Prior discussions have indicated that 32 bit floating point is a 24 bit mantissa and a 8 bit exponent (2**8?). Is there a logical reason this format is called 16.8 float, which sounds like something with a 16 bit mantissa and an 8 bit exponent, which does not add to 32 in most number systems?

Even with integer files, not all samples values will involved rounding/truncation errors from transforms. If the sum of the two (or more) samples, or the result of any operation upon a sample, has less than, or equal to, the number of integer digits (e.g. 16 places for 16 bit), then there is no quantization error, correct?

Likewise, any operation that produces more than X digits will have to be rounded/truncated when working in 32 bit floating point. What is X? 24? 32? or something less determinate, depending on other factors? What factors?

I don't want to alienate people, but why do I get so many “don’t worry about it” replies when I want to know something factual? Is there something in the way I write that comes across as complaining rather than simply asking, or is my writing simply hard to read?

Well, I understand your urge to know things, but often I get the feeling that you worry too much about issues that are so minute that they will never really be a problem even if you made some extreme use of the program. Sometimes I fear you will become paralysed just by analysing too much. I looks as if your on a quest to trace the last pdB deviation.

If this is just a study on itself, fine. If your goal is to "make music", don't worry and get on.

What I’m interested in is quantization error, when does it happen and when is there none?

There's none - period. The rest of that post is total BS. If you do the subtraction accurately (ie, in AA3.0 as I strongly recommend that you use), then you get exactly zero as a result - I tried it. So if you don't, then there's a fault in CE2000 or a fault in what you are doing. And if you go on forming your somewhat strange ideas based on observations of something that may or may not be faulty to a degree, you are going to go on annoying a lot of people - quite unnecessarily.

There might be issues with 'stats' reporting . . . The resolution of report format might easily be different then an FFT transform.  In any case for reasons perhaps as obscure as the post itself I attempted to deconstruct Andy's methodology (one of the obscure reasons is not because I had doubts about the program but because I had doubts about my ability to decipher what it was Andy had done).  The attached txt file reports my results

Something  Andy does not seem to be able to determine is when his frame of reference is fatally flawed.  The 'lens' (i.e. stats report) he is using to analyze his action (invert paste) lacks resolution to be able to return anything but 'artifact' for the thing he claims to want to  analyze.

there are lot's of apps out there that will accomplish Andy's stated task, do not require anyone on the list to speculate whatsoever . . . using the appropriate tool he might or might not find anomalous action in his software.  Or he might actually be able to refine his process so it might be functional . . . you can use a rock a drive in a nail, it's not the preferred tool to construct a modern house, nor is information the rock returns particularly useful in learning how to design a house. I doubt if the CE2K 'stats analysis' is designed to provide a comprehensive, line by line comparison of multiple binaries.  The superficial description suggested, to me, either that he had selected the wrong lens for the task or that something was flawed with the methodology.  As a rule it is generally a sound idea to make sure cables and interconnects are able to transmit appropriate data and are actually attached (that, in this case, is a metaphor). 

I have a sense of what he might be asking but even after eight years of this stuff I can't deconstruct his methodology sufficiently to be sure . . . but I have found him consistently to be so entangled in the minutia of his methodology (not even the minutia of the question, because as I said there are plenty of programs capable of resolving what appears to be his issue without any recourse to personnel on the forum) that no possible response could possibly be acceptable

The one thing, after eight years, I, if not the entire forum, can be confident about is that his claim to be interested in learning this stuff is narcissistically disingenuous . . . I'm pretty sure it is something he can't help or even control and he has never seemed to devolve into deliberate disruptive rudeness

and, over the years, I have learned stuff . . . not from Andy's inquiries but from Steve's deconstruction . . . And, while I do not always succeed, demonstrating similar fidelity to New Year's Resolutions, Andy's posts tend to encourage me to challenge my preconceptions before I start floundering around, beating on things with the nearest rock.

anyway for those interested in what might be superficial basis for Andy's post: used the program, tried to duplicate Andy's approach did not get results that challenged either CE2k's math or reporting  . . .

Prior discussions have indicated that 32 bit floating point is a 24 bit mantissa and a 8 bit exponent (2**8?). Is there a logical reason this format is called 16.8 float, which sounds like something with a 16 bit mantissa and an 8 bit exponent, which does not add to 32 in most number systems?

16.8 float is a non-standard format specific to CoolEdit, in which the mantissa is not normalised, but is held as a 24-bit fixed-point real (in the range +/-32767, with eight fractional bits, hence the 16.8 ), the exponent only being used (in effect) when clipping would otherwise occur.*

Audition can read this, but now uses standard normalised floating-point by default, 'cos that's what the processors do.

Paul


* this description is not guaranteed, but is the best I can do with the published description.

...and that old format was created before the current 32-bit float became a universal standard, and is infintesimally more accurate.  (Shhh!  Don't tell Andy that.)

By the way, a quant. error at -168 dB is down at the 28th bit, making it 1 part in 268,435,456, or a distortion factor of 0.000000373%. 

Sorry Andy, but I have to agree that this is absolutely trivial.

Some might recall from my first post in this thread that I see the residue in Spectral View and on the Frequency Analysis graph. The Statistical Analysis just puts certain numbers on it.

It is real, and it isn’t a program error. It is a consequence of the float format. By first saving my generated files as type-1 24 bit, I lose the extra low order data bits. The rest of the experiment returns the complete silence that everyone else expects.

This arose from a thread I started some years ago in different forum. I’ve posted similar inquiries here, and in a number of other places. When someone starts waxing ecstatic about the great advantage of 24bits and/or higher sample rates, I’ve asked for any sample that, once properly converted to CD standard format, can be distinguished from the original higher resolution.

Someone finally posted some samples that he claims can be successfully identified in validly conducted blind ABX tests, such as those done with PCABX, WinABX, and the plugin in foobar2000. The samples don’t even have any fadeouts or any particularly low level passages that, in the ordinary way of thinking about the problem, might seem to offer the best chance of hearing some difference.

Since I, like apparently most people, can’t hear a difference (the subjective side), I was curious about, objectively, how much difference actually exists. That might be somewhat irrelevant, or maybe it can put some probability numbers on the question.

First, the simple difference between a properly dithered 16 bit version and the 24 bit original is so swamped by the dither, I wanted to be able to remove the dither and look at only the music file. In order to test my concept, I first tried some experiments with generated tone files.

I concluded I could indeed remove the dither but I would end up with a file containing both the “music” data difference between the 24 and 16 bit versions plus the quantization errors from converting to 16 bits plus the quantization errors from mixing the music and dither to begin with. Only the later is unwanted.

Someone pointed out there should be no errors from mixing in floating point format unless one actually clipped (which is rather hard to do). There must be something wrong with my procedure. Thus the query that opened this thread. It might be an unimportantly small amount, but why does it exist at all?

The answer is found in post#143 by 2Bdecided, posted today (February 11, 2009) at 03:39, at
http://www.hydrogenaudio.org/forums/index.php?showtopic=49843&st=125
If anyone thinks the explanation is incorrect, that would also be interesting to read.

The link should open on page 6 of the thread. The current discussion, with its 24 bit sample file links, starts at the top of page 4. My full process for converting to 16 bit, and removing the dither before comparing the 16 bit version with the 24 bit version, is in-between.

The data difference is at -90dB Peak, -98dB RMS Average, which would seem like a very small difference to notice. If someone can think of a way that small data difference might make a significantly larger output signal difference, that could put a different light on the subject.

Some might recall from my first post in this thread that I see the residue in Spectral View and on the Frequency Analysis graph. The Statistical Analysis just puts certain numbers on it.

It is real, and it isn’t a program error. It is a consequence of the float format. By first saving my generated files as type-1 24 bit, I lose the extra low order data bits. The rest of the experiment returns the complete silence that everyone else expects.

No, this is complete BS - big time. I haven't got CE2000 on a running machine at present, but I have got CEP1.2A running - and that's essentially the same engine.

In it, I created your files, at the same level, and saved them twice - once as the default 32-bit 16.8 float and once as the current type 3 default. Doing an inverted mix-paste with both types returns identical results - zero both times. In both cases, the files contain finite data bits - never mind what they represent. If you subtract two identical sets of data from each other, you get zero, regardless of the format. If you don't, then there's an error in whatever was doing the subtracting. But however you look at it, it cannot possibly be a file type fault.

So you've either got settings wrong in CE2000, or screwed it up somehow, or there's a genuine error in CE2000 (which I doubt) - but whatever it is, it's definitively not what you said.

The answer is found in post#143 by 2Bdecided, posted today (February 11, 2009) at 03:39, at
http://www.hydrogenaudio.org/forums/index.php?showtopic=49843&st=125

Since you have the answer, do you still have a question? 

To paraphrase that explanation: it is possible, using floating point, to generate data which has bits below the precision implied by 24-bit integer data; these extra bits are truncated (or maybe rounded off?) when this data is combined with data that goes to full scale.  There is nothing unexpected or surprising there.  In practice it will only affect artificially generated sounds; no microphone or ADC can generate significant data at that level.  Nor will this be audible unless your gain staging is totally up the creek.

I have programmed mathematical problems where this effect was important (inverting ill-conditioned matrices, for instance), and the precise order of operations had to be designed to ensure the maximum precision was maintained at all times - this was simply the equivalent of correct gain staging in audio.

Paul