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.
1. Time domain codecs (lossy modes of lossless codecs)
2. Frequency domain codecs (all mentioned in wiki)
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
2. basically everything that does DCT. MPC is a frequency domain codec. SBC? SubBandCoding?
Yes, the one mandatory-to-implement codec for Bluetooth
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.
Porcuss meant about bitdepth I guess. A sample isn't quite easy to define in lossy codecs.
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?
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.
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?
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
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.
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.)