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: "Tested": codecs at same-signal-different-sample-rate (boring result!) (Read 821 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

"Tested": codecs at same-signal-different-sample-rate (boring result!)

Audio codecs are generally developed on CDDA, and some are less happy than others when fed high-resolution audio. Most likely because the signal is better ... or? Maybe check that: do some behave badly when they see a high (or low) sample rate?

So what I did: "speeded up" a signal by just assigning different sample rates in WAVE file headers. All .wav files have the same samples, but one of them says "play 44100 of these per second", another says "play 96000 of these per second", etc. And slowed down too.

TL;DR: nothing to see here, move on unless you are really curious.

I would not have been worried over small to moderate differences - codecs tuned for actual music taking sample rate into account, will likely not be hi-rez tuned for music transposed up an octave or four.  And without any actual "tuning", just say a strategy of N blocks per second of music, small differences would be expected.  But had an encoder gone off rails, it could have made room for cheap improvements.  Not so, I think.  Maybe a tad for MPEG-4 ALS, but who uses that?

What was done: Took a CD image (a sampler of various artists just in case material should happen to matter, but all rock), exported the PCM to raw headerless file, assigned the signal to sample rates 16, 22.05, 44.1 (original), 88.2, 96, 192, 384 and 655 kiloherz each in their own .wav. Yes 655000 Hz, in part due to FLAC limitations (indeed I used FLAC to generate the thing), in part because I was curious about whether non-standard sample rate would force any encoder out of their comfort zone - nah, it didn't. Played back at 96 and 192 just to hear that I hadn't fxxked up anything more than when I played mom's records at 78 (or at 16 2/3 - later I grew up to love funeral doom metal, but I digress).

All new .wav files then compressed with various reference codecs at default and at a high setting. Except: no patience for more than one ALS mode, no "fast" for refalac, TTA used ffmpeg's encoder which by experience generates same file sizes. Oh, TAK does not support > 192 kHz.


WAV size 431 MB. Compression size (at highest of the 1-2 settings run) included, you see that the expected size order between codecs is maintained with no surprise (again maybe bar ALS).

Details:
* For the "traditionally known as heavy" compressors - OptimFrog (compresses to 252 MB at -10) and Monkey's (256 MB at Extra High) - sample rate does not affect file size by a single byte.
* refalac: only 32 kB difference, size decreasing in sample rate. 273 MB.
* FLAC: 68 kB between 16k (largest) decreasing to 192 (smallest; two higher rates slightly up again) at -5; nearly as much difference at -8. 268 MB at -8
* TTA: 533 kB difference, size decreasing in sample rate. 267 MB.
* WavPack: CDDA largest at default mode (485 kB larger than smallest). With -hhx, differences typically shrink a lot - except an oddball size for 22.05, at 770 kB above 96&192.  262 MB at -hhx.
* TAK: CDDA smallest. 192 kHz was 1190 kB larger at p4m.  Smaller difference at default.  257 MB at p4m.
* MPEG-4 ALS: > 5 MB difference, order opposite of FLAC. 267 to 272 MB. Only default setting run.

Last two months' worth of foobar2000.org ad revenue has been donated to support war refugees from Ukraine: https://www.foobar2000.org/

Re: "Tested": codecs at same-signal-different-sample-rate (boring result!)

Reply #1
Most likely because the signal is better
F**k, what am I even writing?!?

Mods can either TOS8-fix that one - or more likely, leave me and my "better" here on the pillory, as deserved.

Bedtime :-(
Last two months' worth of foobar2000.org ad revenue has been donated to support war refugees from Ukraine: https://www.foobar2000.org/

Re: "Tested": codecs at same-signal-different-sample-rate (boring result!)

Reply #2
* For the "traditionally known as heavy" compressors - OptimFrog (compresses to 252 MB at -10) and Monkey's (256 MB at Extra High) - sample rate does not affect file size by a single byte.
That means no compression parameters depend on the sample rate.

* FLAC: 68 kB between 16k (largest) decreasing to 192 (smallest; two higher rates slightly up again) at -5; nearly as much difference at -8. 268 MB at -8
FLAC has a seek table, and the reference encoder seems to use seek points at fixed time intervals. Since the higher sample rates have shorter play time, the seek table gets smaller as the sample rate goes up.

There is an additional factor that explains the odd high-sample-rate results: FLAC frame headers encode "common" sample rates in fewer bits than "uncommon" sample rates. The two highest sample rates you chose are not in that list of "common" rates, so at those rates there will be an extra two bytes per frame.

* TTA: 533 kB difference, size decreasing in sample rate. 267 MB.
Much like FLAC, TTA has a seek table that gets shorter when the playback length decreases. Unlike FLAC, the block size is directly controlled by the sample rate, so the size difference is at least partially explained by changes in the compression efficiency.

Re: "Tested": codecs at same-signal-different-sample-rate (boring result!)

Reply #3
Yes, and one more thing with FLAC: it defaults to more padding when the signal exceeds 20 minutes. Because, apparently, it thinks that then it is more likely to be a full-album image, which might have more metadata per file, which might justify more padding per file.

Using  --no-padding --no-seektable, the two highest sample rates are 55176 bytes larger than anything else, and that's all - and it scales with -b. (Higher block size means slightly worse compression, but that is a different story.)

Last two months' worth of foobar2000.org ad revenue has been donated to support war refugees from Ukraine: https://www.foobar2000.org/

Re: "Tested": codecs at same-signal-different-sample-rate (boring result!)

Reply #4
Perhaps testing ffmpeg's flac encoder will give more interesting results: that changes the blocksize depending on the samplerate by trying to keep the blocksize a certain time, sticking to the default blocksizes. That time is 105ms for most compression levels, which translates to 4608 @ 44.1kHz, 8192 @ 96kHz, 16384 @ 192kHz and 32768 @ 384kHz

With your test method I assume results are going to be "larger files for larger blocksizes"
Music: sounds arranged such that they construct feelings.

Re: "Tested": codecs at same-signal-different-sample-rate (boring result!)

Reply #5
Perhaps testing ffmpeg's flac encoder will give more interesting results
Biggest differences seen yet! ffmpeg'd (default compression) FLAC files sorted by size. (Afterwards, metaflac --dont-use-padding --remove-all stripped 8246 off both smallest and largest).
22.05 kHz size 282 965 029
44.1
16
96
88.2
192
655 & 384 kHz at same size 289 575 591

Then repeating with -compression_level 11, and the 16 and 22.05 move downwards.  (No metaflac here.)
44.1 kHz size 281 206 276
22.05
96
88.2
16
192
655 & 384 kHz at same size 285 994 572
Still BIG differences.
Last two months' worth of foobar2000.org ad revenue has been donated to support war refugees from Ukraine: https://www.foobar2000.org/

Re: "Tested": codecs at same-signal-different-sample-rate (boring result!)

Reply #6
CUETools:
FLACCL: 1.5 MB difference from 22.05 and 44.1 and to bigger files at higher rates (supports max 192) - and then another 300 kB for the 16.

Flake: 2MB difference, kangarooing as follows:
44.1 is 120k smaller than
22.05 is 800k smaller than
192 < 96 < 88.2 which are quite equal, but more than a MB smaller than
16.
Last two months' worth of foobar2000.org ad revenue has been donated to support war refugees from Ukraine: https://www.foobar2000.org/