Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: What lossy codecs have/support a "given number of bits per sample"? (Read 3232 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

What lossy codecs have/support a "given number of bits per sample"?

Ignorant question that I have hardly ever bothered to think about: Which lossy codecs (1) must, and which ones (2) need not, but may have a given figure comparable to (a) N-bit fixed-point PCM, and/or (b) (mantissa,exponent)=(M,E) floating-point PCM?

... let's say that https://wiki.hydrogenaud.io/index.php?title=Lossy doesn't appear to represent the knowledge on the board.

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #1 –
1. Time domain codecs (lossy modes of lossless codecs)
2. Frequency domain codecs (all mentioned in wiki)

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #2 –
Quote from: rutra80 on
1. Time domain codecs (lossy modes of lossless codecs)
2. Frequency domain codecs (all mentioned in wiki)
Not everything that isn't a variation of PCM, is a frequency domain codec.
IMO it's more accurate to divide it like this:
1. Codecs which are a variation of PCM (the stuff that's encoded is amplitude measurements of the signal at specific regular time points)
2. Everything else

Because 2. also has to include stuff like SBC, Musepack
a fan of AutoEq + Meier Crossfeed

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #3 –
2. basically everything that does DCT. MPC is a frequency domain codec. SBC? SubBandCoding?

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #4 –
Yes, the one mandatory-to-implement codec for Bluetooth
a fan of AutoEq + Meier Crossfeed

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #5 –
Quote
need not, but may have a given figure comparable to (a) N-bit fixed-point PCM, and/or (b) (mantissa,exponent)=(M,E) floating-point PCM?

Any file can be given an average bits per sample if you take the total number of samples and divide by total number of bits. If you mean that this value should apply to each sample in the file and not just the average over the whole file, most lossy codecs don't work like that since they allocate bits dynamically.

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #6 –
Porcuss meant about bitdepth I guess. A sample isn't quite easy to define in lossy codecs.

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #7 –
Yeah, bit depth or "word length" if you like.

One reason that I ask is that I have seen it reported for both Opus and AAC, and I started scratching my head over is-it-even-possible?

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #8 –
Quote from: Porcus on
Yeah, bit depth or "word length" if you like.

One reason that I ask is that I have seen it reported for both Opus and AAC, and I started scratching my head over is-it-even-possible?

In that case, no most lossy (transform, subband) codecs do not have any defined number of bits in a specific sample, just an average for the whole file.

Instead, samples are usually quantized in the frequency domain and then transformed back to the time domain. Individual frequency bands may have had some number of bits defined, but those end up spread over hundreds or thousands of time domain samples.

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #9 –
So I tested the following:
I have a full concert bootleg as .mp3, which I (by way of cue sheet etc) re-encapsulated as .mka with chapters to get tracks blah blah blah. Had MediaInfo and foobar2000 report what they could know about it.

* mp3 "without chapters": no bit depth reported by neither application. As expected.
* mp3.mka with chapters: fb2k reports 16 bits depth. MediaInfo reports nothing about bit depth.
* ffmpeg transcodes mp3.mka to opus.mka with -map 0 and chapters preserved: Both foobar2000 and MediaInfo report 32 bits depth.
* ffmpeg reencapsualates the opus.mka to opus.opus and to opus.ogg: Neither foobar2000 nor MediaInfo report bit depth for any of them.

I was not aware that fb2k would report bit depth on something with mp3 (... @Peter , is this expected?) but when two applications report bit depth for opus-in-mka but neither for opus-as-.opus, then I am starting to wonder if ffmpeg builds faulty Matroska containers or something?



Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #10 –
I believe what's reported here is the bit-depth after decoding to PCM, which is written somewhere into the file header (i.e., bit-stream container). Of course, not every decoder has to obey this.

I think the last codecs which had a true fixed bit-depth per coded sample were low-delay communication codecs like (AD)PCM, MPEG-1 Layer II (MP2) and, possibly, some Bluetooth codecs like SBC and AptX.

Chris
If I don't reply to your reply, it means I agree with you.

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #11 –
Good find. Matroska container has a bits per sample field which is set for these codecs, even though it has no real meaning. It's value depends purely on the application that wrote the Matroska file. It's an oversight on my side that it's shown by foobar2000 at all.
Microsoft Windows: We can't script here, this is bat country.
 

Re: What lossy codecs have/support a "given number of bits per sample"?

Reply #12 –
So ... if anyone feels like bugging ffmpeg devs, good behaviour would be to set this to zero for most lossy codecs?

(At least when the only audio stream is lossy, IDK whether there is one field per stream. And "most" -> keep it "4" for ADPCM I guess.)