HydrogenAudio

To get the picture on how huge  a 16 bits range is, let make an analogy with graph paper in millimeter. A single sheet in A4 format is 21 centimeters by 30 centimeters.

To draw on Y axis the value of a single 16 bits sample on a little millimeter square the size of a pen tip, one would need a sheet (a roll!) of more than 65 meters. That's the height of a building with more than 20 storeys. 7 rolls of 10 meters will do.

(https://i.postimg.cc/3wxdc1Jg/a387a1b3.jpg)

Now let pretend that your hand is shaking while blacken this tiny 1 mm square with the pen. You miss the square and draw the point in the adjacent ones, a +/- 2 mm error in both X & Y axis. You now have reduced the resolution to 14 bits and added (depending the abscissa scale you choose) some jitters.

Could you spot this 2 mm error on the audio signal if it was projected as a picture on the facade of a building big as the Taj Mahal?  Could you hear it ? I doubt it. As to listen to this sound you'll have to stand back at least 50 meters from the facade.

I know that something opposes this analogy:  Hearing works on a logarithmic scale. Even so, analog ICs, PCB, cables, as the paper sheet, work in a linear world. LSB will be kind of submerged in a full 2**16 amplitude.

With 24 bits it's the same story but we'll need 1700 rolls of 10 meters length graph paper to exactly place the sample. 1,700 * 10 m = 17 km or 60 times the height of the Eiffel Tower. Stand back 20 km away. Can you see if the 1 mm2 point is in its right place, not 1 or 2 mm to high ? Look again. And remember that visual perception is much more accurate than hearing


(https://i.postimg.cc/BbrFWKwJ/0e784289.png)

Ask yourself why scientific instruments costing the price of a car are stuck below 16 bits (more a format than a resolution) even for very low speed like 0.2 Hz while you can buy 24 bits audio players for peanuts.

16 bits is "more than enough" but not for the reasons you've described.  A 16-bit digital sample with noise shaping can capture up to 120 dB of signal-to-noise ratio.  There is no music produced or reproduced on the face of the earth that exceeds that, nor can modern electronic equipment be any quieter.

Instead, your analogy strikes me as similar to that made by people who argue higher resolution in images is analogous to higher sample rate in audio: higher pixel density allows finer visual detail, so more frequent samples should create higher audio fidelity.  Those people do not understand the way digital audio works.  A 44 KHz sample rate already can encode all the information needed to faithfully reproduce sinusoidal frequencies up to 20 KHz.  Again, there is no earthly music that requires anything more.

Additional reading:
https://hydrogenaud.io/index.php?topic=106566.0
https://people.xiph.org/~xiphmont/demo/neil-young.html

Anything with at least 1 bit could be "enough", depends on sample rate.

What I would really like to know
What is up with all the oversized images on this forum lately?

What I would really like to know
What is up with all the oversized images on this forum lately?

Keeping up with time that demands increased bit depth even if there is no real need for it?

But seriously, maybe some forum admin could look into sizing defaults.

Our senses are impressively sensitive and scaleable.
16bit in PCM audio is enough but it's on the edge of enough. Undithered 14bit is distinguishable from 16bit.
Our vision is even more sensitive - 24bits for RGB are on the edge of enough, 16 bits are distinguishable from 24bits.
So, while the analogy is nice, it's not universal.

Our senses are impressively sensitive and scaleable.
16bit in PCM audio is enough but it's on the edge of enough. Undithered 14bit is distinguishable from 16bit.
Our vision is even more sensitive - 24bits for RGB are on the edge of enough, 16 bits are distinguishable from 24bits.
So, while the analogy is nice, it's not universal.

One usually have only 8 bits per primary color for distribution (lately increasing to 10 or 12). I would suggest that as the suitable analogy to audio. Having 3 color channels is more like the dual audio channels found in stereo.

You could say that the 3-channel matrixing to YCbCr is somewhat similar to mid-side stereo or low-order ambisonics (?), but even then the achromatic information found in the luma channel can usually be encoded with sufficient precision using 8-10 bits.

-k

What I would really like to know
What is up with all the oversized images on this forum lately?

Looks pretty normal to me with desktop Firefox and default font size? BTW, I reduced the attached image to 251 colors, my screen is 1920*1080 and set to 130dpi.

Our vision is even more sensitive - 24bits for RGB are on the edge of enough, 16 bits are distinguishable from 24bits.
So, while the analogy is nice, it's not universal.

Like Knutinh say a video file is more like a 3 * 8 bits channels audio file.
10 bits by primary color are more than enough  :D for the eyes.
Most of JPEG pic are 3 * 8 bits and they are perfect. Better than a Kodachrome.

Quote from: The Irish Man on 2022-08-10 09:10:25

What I would really like to know
What is up with all the oversized images on this forum lately?

Keeping up with time that demands increased bit depth even if there is no real need for it?

But seriously, maybe some forum admin could look into sizing defaults.

It was just to show the tiny millimeter square  :))
Here 640 width. Looks not to scale on a 22 inch screen. But +150%


(https://i.postimg.cc/Gpsq9f5Q/sheet.jpg)

Additional reading:
https://people.xiph.org/~xiphmont/demo/neil-young.html

"Misinformation and superstition only serve charlatans. So, let's cover some of the basics of why 24/192 distribution makes no sense  [...]. Why push back against 24/192? Because it's a solution to a problem that doesn't exist, a business model based on willful ignorance and scamming people."  ;D

Quote from: The Irish Man on 2022-08-10 09:10:25

What I would really like to know
What is up with all the oversized images on this forum lately?

Keeping up with time that demands increased bit depth even if there is no real need for it?

But seriously, maybe some forum admin could look into sizing defaults.

The OP is using external images (which I believe are always shown full size).
The OP can manually scale the image

[img width=300]https://i.postimg.cc/Gpsq9f5Q/sheet.jpg[/img]

(https://i.postimg.cc/Gpsq9f5Q/sheet.jpg)

The OP could also be manually thumb-nail the image

[url=https://i.postimg.cc/3wxdc1Jg/a387a1b3.jpg][img width=200]https://i.postimg.cc/3wxdc1Jg/a387a1b3.jpg[/img][/url]

(https://i.postimg.cc/3wxdc1Jg/a387a1b3.jpg) (https://i.postimg.cc/3wxdc1Jg/a387a1b3.jpg)

One usually have only 8 bits per primary color for distribution (lately increasing to 10 or 12).

It's worth noting that the move from 8 to 10 bits for video has almost nothing to do with picture quality. It mostly just improves compression efficiency. The main effect on PQ is a reduction in bandng artifacts, but reducing banding also improves compression. Most of the benefit comes from using 10 bits; using 12+ bits is approaching the same snake oil territory as 24/192 audio.

16bit is Red Book standard for CDs.

CDs only make about 22Hz per left and right channel.

CDs only make about 22Hz per left and right channel.

The frequency is limited to half of the sample rate (44,100 samples per second) and this is unrelated to bit depth.

Digital audio is quantized in two dimensions, amplitude and time.

Digital audio is quantized in two dimensions, amplitude and time.

Oh, and typically a space dimension we index by labels "left" and "right".

In video don't forget about HDR and wide gamut, where 8 bits per channel would be far from enough.

What I would really like to know
What is up with all the oversized images on this forum lately?

Yeah man, I'm on my 1990s DX2-66 and my 14" crt screen cannot handle those.

Under laboratory conditions (with higher than typical LCD brightness levels) it was found that the human eye can see somewhere between 600-1000 shades of gray, so it is necessary to have a minimum of 10 bits per channel (1023 levels) for HDR picture quality. It's not that hard to see banding in undithered 24 bit images where the green channel (wavelengths our eyes are most sensitive to) needs high dynamic range.

There are similar limitations in auditory precision in hearing, considering the most transparent psychoacoustic compression is generally limited to an accuracy of 8 bits significant digits and transparent LossyFLAC/etc goes down to 8 bits significant digits, that 16-bit "half" precision is more than enough to fool human hearing with more dynamic range than 16-bit audio. So you can encode masters in less than 16 bits if it's floating point.

Under laboratory conditions (with higher than typical LCD brightness levels) it was found that the human eye can see somewhere between 600-1000 shades of gray, so it is necessary to have a minimum of 10 bits per channel (1023 levels) for HDR picture quality. It's not that hard to see banding in undithered 24 bit images where the green channel (wavelengths our eyes are most sensitive to) needs high dynamic range.

But we can imagine that in the future we'll put fake windows / screen on a wall to replicate a view to the exterior (with some "AI" to show a view relatively to our position - imagine that!). To simulate full range from deep dark night, moon light, to full sunlight, This will need a bigger range than 1024 levels of lumens per cm2 even if the eye is limited to 1024 ones, because of the pupils. I have no idea of the range it will need. Perhaps 16 bits will not be enough  :))

There are similar limitations in auditory precision in hearing, considering the most transparent psychoacoustic compression is generally limited to an accuracy of 8 bits significant digits and transparent LossyFLAC/etc goes down to 8 bits significant digits, that 16-bit "half" precision is more than enough to fool human hearing with more dynamic range than 16-bit audio. So you can encode masters in less than 16 bits if it's floating point.

Converting a 16 bits signal to 8 bits is not really a "compression".
A sample in int16 or float16 have the same number of "shades".

Converting a 16 bits signal to 8 bits is not really a "compression".

It... literally is? By a factor of 2, in fact.

Quote from: biloute on 2022-08-12 22:47:30

Converting a 16 bits signal to 8 bits is not really a "compression".

It... literally is? By a factor of 2, in fact.

So call it a division by a factor of 256 but certainly not compression. If you compress an audio file with FLAC it keep its 16 bits depth. Same thing if you "compress" it to have a more or less same amplitude all along the track with an audio digital compressor, it's still 16 bits after the process.

An experimental format I made previously. Not really floating point but some sort of log approximation, with 8 or 12 bits quantization.
https://hydrogenaud.io/index.php/topic,121181.msg1005031.html#msg1005031

Half-float contains negative zero, infinity and NaN, so in practice the usable values are fewer than 16-bit integer.

An experimental format I made previously. Not really floating point but some sort of log approximation, with 8 or 12 bits quantization.
https://hydrogenaud.io/index.php/topic,121181.msg1005031.html#msg1005031

Half-float contains negative zero, infinity and NaN, so in practice the usable values are fewer than 16-bit integer.

The range of values are not the same but the total number of distinct value possible is the same.


For integer format: 2**32 = 4,294,967,296


For real, float, fixed, etc.. whatever the (sign, expo, etc..) layout:

fraction => 2**24 = 16,777,216
expo => 2**8 = 256

fraction * expo = 4,294,967,296 like for a int32 ou uint32

To elaborate, "usable values" means usable finite and numeric values, not range and other things, I did not mention range in the first place, and your examples don't include half-float as well:
https://evanw.github.io/float-toy/
NaNs and infinites occupied some values, unless repurposed to represent audio sample values, but doing so will break the specs.
Total discrete values regardless of meaning of course are same in 16-bit integer and half-float, this does not need special mention obviously.

[edit]
For example, the 8 and 12-bit companding formats I mentioned in my previous post don't contain negative zero, NaNs and infinities.

Quote from: doccolinni on 2022-08-12 23:30:53

Quote from: biloute on 2022-08-12 22:47:30

Converting a 16 bits signal to 8 bits is not really a "compression".

It... literally is? By a factor of 2, in fact.

So call it a division by a factor of 256 but certainly not compression.

No, that's incorrect. If those 8 bits are still stored in 16 bits (and they're only the 8 least significant bits), then sure. But if the format has been converted from 16 bit to 8 bit (which is implied by "converting a 16 bits signal to 8 bits"), then it is compression, because it takes 50% less space.

No, that's incorrect. If those 8 bits are still stored in 16 bits (and they're only the 8 least significant bits), then sure.

It's rounded, truncated.

But if the format has been converted from 16 bit to 8 bit (which is implied by "converting a 16 bits signal to 8 bits"), then it is compression, because it takes 50% less space.

But it"s the same operation than the one above. Like a cast.

To elaborate, "usable values" means usable finite and numeric values, not range and other things, I did not mention range in the first place,

Okay !

Quote

But if the format has been converted from 16 bit to 8 bit (which is implied by "converting a 16 bits signal to 8 bits"), then it is compression, because it takes 50% less space.

But it"s the same operation than the one above. Like a cast.

Yes, and that's a very rudimentary form of lossy compression. I don't understand which part of this is controversial.

Yes, and that's a very rudimentary form of lossy compression. I don't understand which part of this is controversial.

But a mp3 encoder, PNG or GIF encoders,  or gzip, xz, zstd, etc.. Don't work by truncating numbers.

Quote from: doccolinni on 2022-08-13 23:28:32

Yes, and that's a very rudimentary form of lossy compression. I don't understand which part of this is controversial.

But a mp3 encoder, PNG or GIF encoders,  or gzip, xz, zstd, etc.. Don't work by truncating numbers.

All of those you've listed besides MP3 perform lossless compression, so not comparable.

As for MP3: yes, it does work by truncating (usually referred to as "quantising") numbers. What do you think lossy compression is?

As for MP3: yes, it does work by truncating (usually referred to as "quantising") numbers. What do you think lossy compression is?

mp3 encoding has nothing to do with truncating numbers. Perhaps it use some kind of lossless compression (Like xz, zstd) - I have no idea - over after processing sound in its way. It's like converting a raw RGB picture file in PNG with a reduced palette. I don't call that "compression" even if the file is smaller. It's a transformation. In fact we should only use "compression" when it's lossless.

In fact we should only use "compression" when it's lossless.

https://en.wikipedia.org/wiki/Lossy_compression

https://en.wikipedia.org/wiki/Lossy_compression

I stilll remember the days the text jokes (to early to call them "memes") went like
- "lsy cmprsn" ...
- it isn't lossy when you can recover the original
And then a punchline like Spoiler (click to show/hide)

mp3 encoding has nothing to do with truncating numbers.

Truncating numbers is fundamental to most lossy compression, including MP3. (https://en.wikipedia.org/wiki/Quantization_(signal_processing)) In MP3, truncation doesn't happen on individual samples - instead, a (theoretically) lossless transform is used to turn the samples into frequency components, and those components get truncated.

Perhaps it use some kind of lossless compression (Like xz, zstd) - I have no idea - over after processing sound in its way.

MP3 stores the truncated numbers using Huffman coding, which is a form of lossless compression.

It's like converting a raw RGB picture file in PNG with a reduced palette.

No, it's like saving that raw RGB picture to JPEG. In fact, JPEG makes an excellent parallel to MP3 here: in JPEG, samples are transformed into frequency components, then those components are truncated, then the truncated components are compressed with Huffman coding.

mp3 encoding has nothing to do with truncating numbers.

Incorrect.

Perhaps it use some kind of lossless compression (Like xz, zstd) - I have no idea - over after processing sound in its way.

Yes, lossless compression (as has been mentioned already - Huffman coding) is used on top of truncation/quantisation. But most of the size reduction by far comes from truncation itself.

I believe you on the "I have no idea" part, though.

It's like converting a raw RGB picture file in PNG with a reduced palette.

PNG uses a lossless compression scheme, but if you reduce the colour palette (thereby losing information) in order to achieve an even smaller file size, then that is still a form of lossy compression.

I don't call that "compression" even if the file is smaller. It's a transformation. In fact we should only use "compression" when it's lossless.

Ok, at this point the only thing I can do is to implore you to stop thinking incorrectly and start thinking correctly. Or to put it another way, to just stop being wrong. Because you're wrong.

If it will help, feel free to read the Wikipedia article on data compression (https://en.wikipedia.org/wiki/Data_compression). I will quote here just the first four sentences:

In information theory, data compression, source coding, or bit-rate reduction is the process of encoding information using fewer bits than the original representation. Any particular compression is either lossy or lossless. Lossless compression reduces bits by identifying and eliminating statistical redundancy. No information is lost in lossless compression. Lossy compression reduces bits by removing unnecessary or less important information.

Ok, at this point the only thing I can do is to implore you to stop thinking incorrectly and start thinking correctly. Or to put it another way, to just stop being wrong. Because you're wrong.

I'm not ! But I give up.

If you thing mp3 or jpeg simply works mainly by rounding or truncating samples so how come the result is a file size ratio of 1:10 or more? It's much more complicated !

Here my wiki link too  ;D
https://en.wikipedia.org/wiki/MP3

And I repeat myself, but something like sample=(unit8_t)sample or sample=sample&0xff are not "compression" in any way. Maybe a reduction?!  :D

Anyway, 16 bits is more than enough and that all that matters !

If you thing mp3 or jpeg simply works mainly by rounding or truncating samples so how come the result is a file size ratio of 1:10 or more? It's much more complicated !

You're getting caught up in semantics. Yes, JPEG/MP3 are much more complicated than simple truncation, but truncation is an essential part of lossy compression. The key word is "part". There are many more steps besides truncation, but truncation is still one of the steps.

Quote from: doccolinni on 2022-08-14 23:35:55

Ok, at this point the only thing I can do is to implore you to stop thinking incorrectly and start thinking correctly. Or to put it another way, to just stop being wrong. Because you're wrong.

I'm not !

Incorrect.

But I give up.

Also, for some reason, unfortunately, incorrect - because quite contrary to giving up, you continued:

If you thing mp3 or jpeg simply works mainly by rounding or truncating samples so how come the result is a file size ratio of 1:10 or more? It's much more complicated !

I see you've decided to go the route of having the word "simply" do the heavy lifting instead of actually engaging your brain and thinking through what both I and everyone else has been telling you.

Yes, most of the space savings in both MP3 and JPEG actually do come from truncation/quantisation itself, but it is also true that some pre-processing is done on the raw data before the aforementioned truncation, and it is true that entropy coding is used on top of truncation to achieve even greater compression.

And I repeat myself, but something like sample=(unit8_t)sample or sample=sample&0xff are not "compression" in any way.

Yes, it is compression, because the output takes up less space than the input, and that is literally the defining characteristic of what "compression" is. For the love of God, please either understand this ridiculously simple concept, or listen to yourself and actually "give up".

If you thing mp3 or jpeg simply works mainly by rounding or truncating samples so how come the result is a file size ratio of 1:10 or more? It's much more complicated !

Because the quantification is not applied to each sample individually - and why should it, a single "sample" is just a ... sample. You don't listen to individual samples.
Signal compression works by transforming the signal into a series of components.
Lossless compression is about transformations that can fit the entire signal into less space.
Lossy compression is about (2) finding out how which and how many terms of the transformed series of components to include (discarding the rest - that is the quantification/truncation part) and (1) find a transformation that facilitates the second step.
Lossy compression also has a size/"quality" trade-off element, whereas lossless compression if found at one extreme of that consideration. Implementations trade off against computational effort as well.

Have a brief look at https://en.wikipedia.org/wiki/Discrete_cosine_transform , and then at https://en.wikipedia.org/wiki/Modified_discrete_cosine_transform .

https://youtu.be/Kv1Hiv3ox8I

Because the quantification is not applied to each sample individually - and why should it, a single "sample" is just a ... sample. You don't listen to individual samples.

Exactly.  See "Reply #19 – 2022-08-12 22:47:30" it all started here.

Converting a 16 bits signal to 8 bits is not really a "compression".

Have a brief look at https://en.wikipedia.org/wiki/Discrete_cosine_transform , and then at https://en.wikipedia.org/wiki/Modified_discrete_cosine_transform .

And it doesn't work with simple (uint8_t)sample16. Nowhere !

Converting a 16 bits signal to 8 bits is not really a "compression".

Yes it is.

Quote

Have a brief look at https://en.wikipedia.org/wiki/Discrete_cosine_transform , and then at https://en.wikipedia.org/wiki/Modified_discrete_cosine_transform .

And it doesn't work with simple (uint8_t)sample16. Nowhere !

And?
You were already told:

truncation doesn't happen on individual samples - instead, a (theoretically) lossless transform is used to turn the samples into frequency components, and those components get truncated.

Quote from: Porcus on 2022-08-15 07:34:37

Because the quantification is not applied to each sample individually - and why should it, a single "sample" is just a ... sample. You don't listen to individual samples.

Exactly.  See "Reply #19 – 2022-08-12 22:47:30" it all started here.

Converting a 16 bits signal to 8 bits is not really a "compression".

All right. It is a dumb lossy compression.
"dumb" either as in "stupid" - if you want to maintain fidelity, there are more efficient ways;
or
"dumb" as in "dumb phone" as a contrast to "smart phone": a primitive thing that might still be in use because it solves a specific problem.

The reason why I wrote that you "don't" perform lossy compression on each individual sample, is the "stupid" part of it, but sure it is not the only possible application: if you have a 96k/24 signal that you want to fit on a CD there is nothing stupid in using the "dumb" LPCM format that actually will do. So in that case you do. It gives you a lossy representation of the 96/24, of course.

f you have a 96k/24 signal that you want to fit on a CD there is nothing stupid in using the "dumb" LPCM format that actually will do. So in that case you do. It gives you a lossy representation of the 96/24, of course.

Yes, in that case you kind of right... 

But since that post I think one should use the word "compression" only if it lossless  ;D

Reduction, depletion, anything else than compression for mp3, jpeg & co. Because it's clearly not except for the file size. That's my next crusade !

Oh, but then take Rocinante over to the video department.

Video is nearly always compressed - lossily. But it is not uncommon among the video folks to say "lossless" for what we call "transparent", meaning it is lossy but nobody will ever see the difference.

Talking about compression, anyone have try nncp from the genius Fabrice Bellard (https://en.wikipedia.org/wiki/Fabrice_Bellard) ?

https://bellard.org/nncp/

I can't, on x86, make say: "Your CPU does not support AVX2+FMA - exiting"
on ARM: libnc.so: file not recognized.. pfff

It's text oriented but I wonder what's the effect on a wav file.

Quote from: biloute on 2022-08-15 16:11:01

Converting a 16 bits signal to 8 bits is not really a "compression".

Yes it is.

I tried that, it didn't work.

We have to re-educate each new generation (10-12 years) eh?

16 bits are already enough... and if there are golden ears who pass ABX versus 24 bits, there is then no way for them to clear noise-shaped dithered 16 bits.

https://xiph.org/video/vid2.shtml --  select the bit depth chapter.

https://downloads.xiph.org/video/Digital_Show_and_Tell-720p.webm

We have to re-educate each new generation (10-12 years) eh?

16 bits are already enough...

I am not sure if the grand misconceptions are "at the 17th bit". Rather I suppose that what makes the quacks rich would rather be
* Sampling rates in the six-figures - current record (?) 768k, to capture the degradation when running a 352.8 DXD through an analog tape. (https://hydrogenaud.io/index.php/topic,93853.msg1006575.html#msg1006575)  Sure this is always 24 bit, but 24 bits isn't enough to impress anyone, so ... that other number must increase. (Of course the "third" number - channel count - would make an audible difference!)
* DSD. Just an impressive bit-rate and file size, but quite a useless format for audio that has been processed.
* The MQA scam. Tidal has put their CDDA FLAC streaming at mid-tier, but it touts above-CDDA to be from the "Master". Yeah they still tout bit rate, but that is now a secondary marketing spin. And MQA isn't the master, it is a lossy damn lie.
* Old fashioned gear alchemy. $10 worth of components in $100 wrapping (= painting the components black, and putting them in a low-run custom-made shiny enclosure) to sell for $1000.


(What I am waiting for is an artist to offer their 352.8/24 DXD with the explanation "I know you cannot hear the difference, but this is the file I produced on my workstation and sent off. If you kinda want what left the artist's hand, then this is it."
Optionally "For an extra charge, I can downconvert it for you and add a signed PDF saying 'This file created from DXD on the orders of [your name]'." More honest than selling the bitrate itself.)

* Sampling rates in the six-figures - current record (?) 768k, to capture the degradation when running a 352.8 DXD through an analog tape.   Sure this is always 24 bit, but 24 bits isn't enough to impress anyone, so ... that other number must increase. (Of course the "third" number - channel count - would make an audible difference!)
* DSD. Just an impressive bit-rate and file size, but quite a useless format for audio that has been processed.

Looks like my prediction in 2016 was not too far from the reality. One thing I could not predict is the "fourth" number: the SINAD pissing contest. The EMU products I mentioned only have about 101-105dB SINAD.

If you talk about price, E-MU 1212m with 115dB SNR (loopback) and 24bit 44-192khz support only cost $200 in 2004, in 2005, X-Fi XtremeMusic, unlike Audigy which supports native 44/48/88/96khz with 109dB DAC and 102dB ADC only cost $128, in 2007, Asus Xonar DX with 44-192khz support and 117dB SNR (loopback)...

Audio formats like 24/96 and DSD already have more than 10 years of history (as stated by other members in earlier discussions in this thread). Nowadays placebophiles already talking about 32-bit 768khz PCM and DSD512.

Maybe ten years later people will talk about 64-bit 2.8mhz PCM or DSD4096, or some other new formats. 24/96 will become pure crap. Who still cares about Lavry's theory? "Engineers" will write some new papers about why Nyquist's theory is flawed, how the dots are connected, how the XtraFidelityMastaXD format override the difficulties in the past 30 years and so on. Are you prepared to argue with those people and say 96khz+ can cause distortion?

The last paragraph... MQA was announced, but not commercially available to consumers yet, IIRC.

Oh, why settle for 32-bit when there is 64-bit float that both subsubes 32-bit float and 32-bit integer and is in actual use? You know ... (https://www.audiosciencereview.com/forum/index.php?threads/does-dsd-sound-better-than-pcm.5700/page-35)
Aaaand, I was not at all aware until Bryant mentioned it (https://hydrogenaud.io/index.php/topic,122626.msg1012646.html#msg1012646), but ... 80-bit float with AIFF for over thirty years? Oh they should have known, those who were touting AIFF as superior to WAVE only ten years ago, when when ... hm, B&W had a download service that offered AIFF but not WAVE. 

... but float is inherently inaccurate, right? No high fidelity about that, at least not compared to vinyl.

The "advancement" in bit-depth and sample rate has nothing to do with transparency, or whether people have watched Monty's video/article or not. It is simply because technology has evolved to the point that "hi-res" (24/192) production can be made on a notebook and a $100 interface with built-in mic and instrument preamp. Low quality analog equipment, poor acoustic treatments, inexperienced studio workers etc don't change the fact the recording format is indeed "hi-res". Recently 32/768 or DSD256 recording interfaces are still more expensive, like $2000, but labels just need to sell dozens of "one-step" vinyls or Studer degraded processed hi-res files to cover the cost.

Now AKM has a 1536kHz 64-bit chip, likely integer as the product brief talked nothing about float and AD/DA chips are all integer. Pay attention to the specs before making any doubt as -153dB THD+N and 156dB S/N are in digital domain.
https://www.akm.com/eu/en/products/audio/audio-dac/ak4191eq/

DAC is on a separate chip accepting 7-bit multi-MHz modulated data, with analog specs:
https://www.akm.com/eu/en/products/audio/audio-dac/ak4499exeq/

While a separate chip for digital processing prior to analog conversion is not a new idea (Google SAA7030), this AKM chipset is a new product and I have not seen any actual DAC-in-a-box using this chipset on the market yet, it is not hard to imagine a few years later single-chip DACs can do the same thing or even better, at least in digital processing like filter and modulator, as 150dB-ish digital performance is not really all that ground-breaking these days. At that time 64-bit float will have the same "issue" that it can only losslessly represent 54 bits of integer within +/-9007199254740992.

Now AKM has a 1536kHz 64-bit chip, likely integer as the product brief talked nothing about float and AD/DA chips are all integer. Pay attention to the specs before making any doubt as -153dB THD+N and 156dB S/N are in digital domain.
https://www.akm.com/eu/en/products/audio/audio-dac/ak4191eq/

Extreme high-res playback: PCM 64-bit/1536kHz,

To return to my analogy, 1 bit among 64bits is like 1mm on a 18 trillion kilometers sheet.

20 millions times the total journey of Apollo 11  ;D

(https://farm2.staticflickr.com/1208/5105040212_346b792ee5_z.jpg)

Don't forget the dithering !

Digital audio is quantized in two dimensions, amplitude and time

Actually, sampling (https://en.wikipedia.org/wiki/Sampling_(signal_processing)) and quantization (https://en.wikipedia.org/wiki/Quantization_(signal_processing)) should not be confused.

Now AKM has a 1536kHz 64-bit chip, likely integer as the product brief talked nothing about float and AD/DA chips are all integer. Pay attention to the specs before making any doubt as -153dB THD+N and 156dB S/N are in digital domain.
https://www.akm.com/eu/en/products/audio/audio-dac/ak4191eq/

DAC is on a separate chip accepting 7-bit multi-MHz modulated data, with analog specs:
https://www.akm.com/eu/en/products/audio/audio-dac/ak4499exeq/

OK. To prevent years later people posting in this thread saying there were floating point audio AD/DA chips, find these datasheets:

YM3014B
YAC512
YAC513

Looks like the reason for floating point was that these DAC chips are designed to work with some vintage Yamaha FM synth, including the popular OPL chips, which also used floating point operations.
https://www.righto.com/search/label/dx7

OK. To prevent years later people posting in this thread saying there were floating point audio AD/DA chips, find these datasheets:

YM3014B
YAC512
YAC513

Looks like the reason for floating point was that these DAC chips are designed to work with some vintage Yamaha FM synth, including the popular OPL chips, which also used floating point operations.
https://www.righto.com/search/label/dx7

Think you need to be a bit clearer, actually.
Just reading aloud it looks like you are first saying that you don't want people to believe that they were using float, and then trying to explain why they were using float.
From the DX7 link it seems they had a 12 bit signed and two bits for an exponent. That means some floating-point involved - but not necessarily in the conversion to analog. (And, a 16-bit integer representation can losslessly contain the range.)

Think you need to be a bit clearer, actually.
Just reading aloud it looks like you are first saying that you don't want people to believe that they were using float, and then trying to explain why they were using float.
From the DX7 link it seems they had a 12 bit signed and two bits for an exponent. That means some floating-point involved - but not necessarily in the conversion to analog. (And, a 16-bit integer representation can losslessly contain the range.)

I am not trying to explain things in great detail from the DX7 article -- I don't have the actual hardware, and I can't completely decipher what the author of that article wanted to explain.

The official datasheet, for example YAC512, which is supposed to be used with the OPL chips (DX7 was "OPS" and I don't know the differences in detail), indeed identified itself as a floating point DAC chip.
https://www.datasheets360.com/pdf/2132239016875191991
This part explains the things in an OPL chip before sending to the DAC chip:
https://en.wikipedia.org/wiki/Yamaha_OPL#Internal_operation

According to the datasheet I believe 16-bit integer is compatible in terms of numeric representation, using floating point in these specific applications could be due to lower production cost, better yields, simpler hardware design when used with the specific Yamaha synth chips and so on.

Wikipedia tells me the DX7 was launched in 1983, which is then a little bit later than the first CD player, Sony CDP-101 CD with a 16-bit DAC. (Infamously, just one at 88200, alternating the channels.)

DX7 would work at a rate of 768 (= 48*16) kiloHz to accommodate 16 voices. Here with two:
(https://static.righto.com/images/dx7-output/waveform-mux.png)
... and then with low-pass filter:
(https://static.righto.com/images/dx7-output/waveform-filtered.png)
(Oh, digital = staircase rant.)

just one at 88200, alternating the channels.)

I never heard of that but you're right. This solution is weird & complex.

Id say changing bitrate from 16 to 8 is compression. compression of dynamics.

Id say changing bitrate from 16 to 8 is compression. compression of dynamics.

Right, but 8 or 16 are not bitrate !

Right, but 8 or 16 are not bitrate !

"Bits per sample" is a bitrate.

Specifically, the rate of bits - you'd never guess it - per sample.

Quote from: biloute on 2022-08-28 18:59:55

Right, but 8 or 16 are not bitrate !

"Bits per sample" is a bitrate.

Specifically, the rate of bits - you'd never guess it - per sample.

Sample depth is not strictly speaking a "bitrate" even if eventually the bitrate depends on the depth.

Sample depth is not strictly speaking a "bitrate" even if eventually the bitrate depends on the depth.

Yes it is, although I recognise your incessant obsession with assigning various terms more restrictive definitions than their actual definitions, so I concede that in your fantasy world you're correct. The only problem is that the rest of us don't live in your fantasy world.

I will surely not say that my CD-ripped FLAC files have a "bitrate" of "16".
There are several obvious reasons it would be inadequate. Here are a few statements that are generally perceived as true, and would then have to go out of the window:

"FLAC bitrate depends on the number of channels."
"FLAC bitrate is lower than for uncompressed PCM, except for the most noise-alike signals."
"FLAC bitrate depends on encoder settings."
"FLAC employs a wasted bits strategy, so if you zero-pad a 16 bit PCM signal to 24 bits, the FLAC bitrate is virtually unchanged."

I will surely not say that my CD-ripped FLAC files have a "bitrate" of "16".

Right, because it's not a "file bitrate" as such, but a sample bitrate. Regardless, it is a bitrate. Not every "rate" is "per unit of time".

Bit depth is not bitrate. It seems you talk nonsense in several topics.

Right, because it's not a "file bitrate" as such, but a sample bitrate. Regardless, it is a bitrate. Not every "rate" is "per unit of time".

There's no "rate" for a "sample" whatever its depth / size as it's sampled in "no time" - its instantaneous. At least in direct-conversion.

Yes it is, although I recognise your incessant obsession with assigning various terms more restrictive definitions than their actual definitions, so I concede that in your fantasy world you're correct.

It's because my native tongue is Kobaïan (https://en.wikipedia.org/wiki/Magma_(band)#Koba%C3%AFan)  :D



Last Edit: Today at 15:34 by korth


How dare you !

Kommand'öh!