Bits Are Bits! Right?

[andrewski]

Cakes, diapers, and wikipedia.

Got it

 

[bigshot]

I don’t think all opinions are perfect.

 

[gregorio]

Since I don't do music (or movie) streaming, I have no idea how a streaming client would deal with that (error message, concealment, dropping the bit rate, something else?)

The TCP requires the receiving device to acknowledge reception of packets, if that acknowledgment is not received it automatically resends it. TCP guarantees that all bytes received will be identical and in the same order as those sent. It doesn’t however guarantee that all bytes will actually be received, in which case the streaming client will simply stop playback once it’s buffer is exhausted if it doesn’t receive the error free data, and you’ll sit there waiting in silence until it does.

Some clients of streaming media can contact the server and request the data be sent at a lower bit rate (more highly lossy compressed) if this condition persists or if it detects a poor connection status that cannot keep up and likewise step up the bit rate again when the connection improves, still no errors of course though. This tends to be more common with video streaming services as video commonly requires around 20 times more bandwidth than even the highest bitrate lossy audio codecs. I believe Spotify is capable of this functionality but your connection would have to be pretty horrendous by modern standards to trigger it, I don’t know if any other music streaming services have it.

G

 

[bigshot]

If you clearly hear problems, you have problems. If you don’t, you don’t. Digital doesn’t generally error subtly.

 

[Blackwoof]

Lossless codecs just trim down redunant data. If Noise & Electronic gets 350 ~ 500kbps It found repeating bits that can be reduced to single number. For ambient/ambient like music It because It dynamic range covers 6 ~ 12-bit. The only issue Is the infamous bit rate bloat when fails to compress something you get 1412 ~ 2400kbps, You'd think they just cap at 1411kbps in that case.

Weirdly noticed FLAC 1.4 & newer with -8 & custom settings can rival other codecs.

 

[alcarvalho]

Lossless codecs are just like other lossless compression algorithms used to compress files like zip, rar, gz, bzip2. The only difference is that they're optimized for audio, which makes them more efficient at compressing it.
You can verify that the data is the same by decompressing it (or decoding it) and comparing what comes out of it with the original file.

This whole debate about data being lost in internet transmissions is very amusing, though.

 

[ericj]

Lossless codecs just trim down redunant data. If Noise & Electronic gets 350 ~ 500kbps It found repeating bits that can be reduced to single number. For ambient/ambient like music It because It dynamic range covers 6 ~ 12-bit. The only issue Is the infamous bit rate bloat when fails to compress something you get 1412 ~ 2400kbps, You'd think they just cap at 1411kbps in that case.

Weirdly noticed FLAC 1.4 & newer with -8 & custom settings can rival other codecs.

Lossless means lossless. Nothing is thrown away. Lossless data compression is just complicated methods of finding new ways to describe the information exactly.

 

[BobG55]

I came across this video on YT. I thought it might interest some :

 

[2leftears]

One thing not mentioned in the video (unless I missed it) is that floating point arithmetic is far more computationally intensive than integer arithmetic. So fine for use in DAWs during mixing but you are unlikely to come across floating point support in the core DAC/ADC filtering and conversion.

 

[gregorio]

One thing not mentioned in the video (unless I missed it) is that floating point arithmetic is far more computationally intensive than integer arithmetic. So fine for use in DAWs during mixing but you are unlikely to come across floating point support in the core DAC/ADC filtering and conversion.

Is it really computationally significant these days though? Some field recorders, even some cheap (<$100) consumer models, rely on 32bit float conversion. Although if I remember correctly, they cascade 2 or more fixed point ADC chips with wildly different gain structures and then calculate a 32bit float output and obviously they must also be able to do the reverse DAC process, in order to listen back to the recordings. The advantage is that neither limiters nor microphone pre-amps are required and the recording cannot be digitally clipped/overloaded. I presume some DACs do something similar, because it’s cheap and it could provide some good looking specs.

G

 

[2leftears]

Is it really computationally significant these days though? Some field recorders, even some cheap (<$100) consumer models, rely on 32bit float conversion. Although if I remember correctly, they cascade 2 or more fixed point ADC chips with wildly different gain structures and then calculate a 32bit float output and obviously they must also be able to do the reverse DAC process, in order to listen back to the recordings. The advantage is that neither limiters nor microphone pre-amps are required and the recording cannot be digitally clipped/overloaded. I presume some DACs do something similar, because it’s cheap and it could provide some good looking specs.

G

It is quite possible that technology has moved on from what I recall gregorio.

Floating point arithmetic used to require slow kernel routines executed by the CPU (in computers). Then came along the dedicated floating point arithmetic co-processors. Then floating point engines were embedded on the CPU. It is quite feasible that they have now managed to also incorporate them in real-time digital filters. Cascading fixed point ADC chips as you suggest is one possible implementation for ADCs. I don't quite understand what they are doing there though; I would imagine turning fixed point into a floating point output is computationally a lot simpler than actually doing the type of floating point calculations that might occur in a DAW, but I could be wrong (turning an integer into a floating point representation is fairly trivial, as is multiplying integers. Multiplying two non-integer floating numbers or doing logarithmic floating point operations is a whole different ballgame.)

 

[gregorio]

Cascading fixed point ADC chips as you suggest is one possible implementation for ADCs. I don't quite understand what they are doing there though; I would imagine turning fixed point into a floating point output is computationally a lot simpler than actually doing the type of floating point calculations that might occur in a DAW, but I could be wrong (turning an integer into a floating point representation is fairly trivial, as is multiplying integers. Multiplying two non-integer floating numbers or doing logarithmic floating point operations is a whole different ballgame.)

I’m not sure exactly what they’re doing either, I’m not even sure that information is in the public domain but from what I understand it’s not entirely trivial (relatively). Along the lines of; each input signal is converted by two oversampling 24bit ADC chips with very different calibration points (gain) and the outputs are scaled and combined at 32bit float.

A DAW is running on a CPU that probably has several orders of magnitude more processing power but then a modern computer (say a Mac Studio) can easily run over 1,000 audio channels all at 64bit float, along with hundreds of 64bit float plugins and various 64bit summing/sub mix channels. So, many orders of magnitude more demanding than a relatively computationally trivial 2 channels of 32bit float conversion.

G

 

[Davesrose]

Is it really computationally significant these days though? Some field recorders, even some cheap (<$100) consumer models, rely on 32bit float conversion.

I don’t think it is from a hardware perspective. There are current prosumer hybrid video/photo cameras capable of recording 32bit float audio. So that means a standard computer running given software has more than enough resources to process 32bit audio. I’m sure it’s been made more trivial from the popularity of 3D graphics-that has relied on 32bit float raytracing. 32bit float actually being faster to render than 16bit integer (with the caveat that it takes up a larger file size).

 

[2leftears]

I don’t think it is from a hardware perspective. There are current prosumer hybrid video/photo cameras capable of recording 32bit float audio. So that means a standard computer running given software has more than enough resources to process 32bit audio. I’m sure it’s been made more trivial from the popularity of 3D graphics-that has relied on 32bit float raytracing. 32bit float actually being faster to render than 16bit integer (with the caveat that it takes up a larger file size).

Well, this is where I am uncertain. When "recording 32bit float audio" is mentioned, what floating point operations does this actually involve?

Taking a binary fixed point A/D sample and turning it into a binary floating point representation is a simple format change that only involves bit shifting to form the mantissa, and an according adjustment of the exponent. That's a different ball-game from actually doing real-time filter calculations in 32bit float, but it could well be that for the latter the required float processors for use in consumer portable equipment are now available.

 

[Davesrose]

Well, this is where I am uncertain. When "recording 32bit float audio" is mentioned, what floating point operations does this actually involve?

Taking a binary fixed point A/D sample and turning it into a binary floating point representation is a simple format change that only involves bit shifting to form the mantissa, and an according adjustment of the exponent. That's a different ball-game from actually doing real-time filter calculations in 32bit float, but it could well be that for the latter the required float processors for use in consumer portable equipment are now available.

Since consumer CPUs are 64bit, consumer recording devices have the memory/processors for recording and storing 14bit RAW video/32bit 2 channel audio, and OSes have been optimized for 32bit processing for awhile, it may be more trivial to store the recorded audio as 32bit float, and continue to process as 32bit. As for what calculations are involved for real-time filters....I'm sure that's dependent on how the software was coded. For example, when Maya was first compiled for the Mac, I found it twice as slow at rendering raytraced images as compared to a PC with NVidia card (because they hadn't worked on a native compile for OS X).

There's a popular commercial grade video editing suite (that's cross platform) called DaVinci Resolve. It has a very capable free version-even the free version accepts Atmos ADM files coming from an audio engineer. Then it can analyze that audio format and convert to a 24bit 5.1/7.1 Dolby Digital Plus/TrueHD audio track with Atmos JOC stream. Along with that, it looks like it does support 32bit float audio as well. Just checking Black Magic forums, videographers say that they're using 32bit float to be able to adjust up to 192dB DR (the recorder then needing multiple ADCs). All of this can be done on a current $1000 computer. It just takes longer to render everything compared to a high end computer, or your preview playback might not be smooth if you have a lot of tracks.

Anyway, this is above that YT video. I don't think it addressed what bit integer vs float is. It's easier to understand from a programming perspective. It's about how large of a number you can store in memory. In C#, integer: -2,147,483,648 to 2,147,483,647 (32bit memory address), double float: ±5.0 × 10−324 to ±1.7 × 10308 (8bit memory address). Depending on how your audio software was coded, it has an effect on how efficient it is in processing integer or float. All of it is for consideration with audio engineering, and isn't relevant for playback of consumer media (as even the most basic computer can handle filters with 16/24bit stereo).

Edit, also saw your post about how images are handled over the internet. They are treated progressively. Back in the days of dial up modems, a web page would load an image such that it would first fill the whole image area with less resolution. As it receives more packets, it fills the image area with the full resolution of the image. So if the transmission was halted, your image would still be fully rendered, but blurry/pixelated because all of its resolution was not received. Video buffering with current video streaming works in the same manor. First, your video service determines if your playback device supports HD or UHD. If it supports HD, it will send a 1080p video. If there's not enough bandwidth with your internet speed, the video will look more pixelated (because the buffer is not getting the full 1080p resolution for every frame). A UHD stream is very different as it has a different color space (more dynamic range), 4x the resolution, and can have an audio track that's 5.1 with Atmos JOC. That's why it needs more than double or quadruple the bandwidth as HD.