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 for the effect of stereo decorrelation (mid/side) (Read 7867 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #25 –
Quote from: bryant on
Thanks again Porcus for your meticulous testing! Like you say, not the most useful files for choosing a compressor, but interesting to get down to the nuts and bolts!
Full consent!

Quote from: bryant on
One of the most common types I found was where the PCM values had obviously been multiplied by some value greater than 1 and just truncated (not dithered) resulting in regularly spaced missing values. I was able to squeeze these out (losslessly, of course) and get significantly better compression, in some cases then blowing WavPack past all the competitors.
I tried  the same for Tak when i noticed that Optimfrog had implemented such a  feature. Optimfrog also seems to take advantage of non uniform quantization (12 bit DAT e.g.). My test corpus was quite small but i too got the impression that most affected files were comparatively old recordings. I am not even sure if there was at least one example in the music i bought in the last 15 Years.

Quote from: bryant on
In the end I decided that this was not worthwhile. For one thing I feared that perhaps my rather old CD collection was not representative and modern mastering tools would not create audio like this any more. And of course this was going to be slow and create enormously complex code. It was an interesting exercise and it would have been fun to release a WavPack that significantly bettered existing encoders on specific files, but in the end thought better of it.
Same conclusion here. And i have to admit i wasn't smart enough to find a detection algorithm that would have been fast enough by Tak's standards. Furthermore Optimfrog's savings still were twice as large for not few of my test files.  To do better i would have to modify far more of the (quite well-tuned) existing codec than i wanted to.

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #26 –
Quote from: TBeck on
I tried  the same for Tak when i noticed that Optimfrog had implemented such a  feature. Optimfrog also seems to take advantage of non uniform quantization (12 bit DAT e.g.).

You guys and Florin - who has been fiddling around with an asymmetric frog extension too! - should stick your heads together to see what you can unify.
Take one letter from each of WavPack, TAK and OptimFROG, in that order, and hope that it doesn't make World of Warcraft crash. If that is a problem, bring on board the ALS for WT A(ctual) F.  :D

(The serious part of this is that it is unrealistic to extend FLAC, as it is probably found in too many non-upgradeable embedded devices - but it could bring optimizations to WavPack, Matroska to TAK and playback support to the frog.)

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #27 –
Oh, and you must leave it to @TBeck to announce it. Just make sure he doesn't miss the date by less than an hour.


... and to new HA readers, here is a classic in the history of lossless audio: 
Once upon a time, on April 1st, someone posted about a codec compressing to sizes smaller than Monkey's High and at speeds like this.

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #28 –
Would it be possible for any lossless codec to get anywhere close to RAR with stuff like this? It's ZX Spectrum beeper PWM.

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #29 –
I suspected that these files have repeating patterns, and yes: when I cut one of them - the biggest, the DarkFusion - into one second segments and compressed each separately with xz -9 -e, file sizes increased by forty percent.

Here is the point: If you process 162 files with a general purpose processor that looks for inter-file patterns, it will detect that file 3 and file 151 are identical, and virtually compress away one of them.
An audio format meant to be streamable doesn't do that. After two and a half minutes you get an instruction that says "repeat segment seconds 3-4". Yeah sure I haven't stored that.
An audio format not meant to be streamable ... go ahead if you want to, and you will be able to outfox some other codecs on some samples yes, but ... is it worth it?

(WavPack beats all the audio codecs on that track though - but you have to use reference WavPack, not ffmpeg.)

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #30 –
Really have you proof for your "claims"? FFmpeg wavpack encoder is marginally different from wavpack reference ones.

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #31 –
Quote from: mycroft on
Really have you proof for your "claims"?
Files appear too big to attach, so please go to https://www.sendspace.com/filegroup/JEjBiar2HYKPs2fq9zFAhQ to find encodes of the DarkFusion.wav audio:
* a 7.47 MB file produced using reference WavPack.
* the 8.74 MB file produced by recompressing the former by ffmpeg 5.0 using the awfully slow -compression_level 8.

Now open the WavPack file and see what mode it is. Hint: it is not "high". In case you will bother to even look at it - last time I took the effort to upload to you any evidence in form of a file, you just ignored it and never came back to the topic at all.


Quote from: mycroft on
FFmpeg wavpack encoder is marginally different from wavpack reference ones.
ffmpeg WavPack produces version 4 files.
Above I used the newest reference WavPack.

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #32 –
Yes. I just tried to download those files, and sendspace is on scheduled maintenance. Why I ever bothered to visit this thread to get proofs for "bold" claims.

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #33 –
Are you calling fake just because Sendspace temporarily is on maintenance? Do we need to teach you how to download WavPack and ffmpeg and try for yourself?

In "honor" of this bullshit of yours, I re-ran it - this time through WavPack 4.80 with and without --optimize-mono, which explains the whole thing:

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #34 –
These files are technically stereo but the content is mono - both channels should be the same.

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #35 –
Again I get attacked by brave user of this forums, next time use -optimize_mono switch if you will ever be bothered again.

Hope your smart team is doing well.

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #36 –
Why I ever bothered to write decoder for TAK? Users are typically ungrateful as always. Wanted to write RKA decoder too, but looking how are users very ungrateful I will pick something else to do and will never ever be bothered with evil users again.

Re: "Tested": codecs for the effect of stereo decorrelation (mid/side)

Reply #37 –
Quote from: mycroft on
Hope your smart team is doing well.
Mine? "team"? I'm just my arrogant swiney self, not affiliated with any codec developer(s). Bark up a different tree.

My issue with you here at the forum is not what code you make elsewhere (if you implemented the TAK decoder, then I am grateful even if I don't use TAK - and it was a better choice than RKAU yes). But your behaviour here isn't ... constructive.

Like, going full denial just because sendspace has a temporary downtime (that still lets you see the files!)?

And had you a solution to the TTA error handling crap or had you not? Hard to tell, and with that attitude, people will just shrug it off as useless.