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.
Recent Posts
2
Lossless / Other Codecs / Re: Lossless codec comparison - part 3: CDDA (May '22)
Last post by ktf -
Also offering the fastest encoder, with -p0, but we knew that.
Of note when comparing FLAC and TAK: in this comparison FLAC does MD5 summing (as it does this by default) and TAK does not (as it does by default), if I'm not mistaken. I didn't check, so if default behaviour of TAK recently changed, this is untrue. Calculating an MD5sum at these speeds is about 30% of the work, so it makes quite a difference.

Quote
* Why Monkey's has to decode slower than it encodes ...? (TTA does that too, and refalac "fast")
I am unfamiliar with the inner workings of these codecs, but I would conjecture that it has to do with the bitreader being dependent on the rest of the decoder.

In FLAC for example, the residual can be read without knowing anything about the predictor except its order. So, most FLAC decoders first read an entire subframe before actually calculating any sample values.

If this is not possible because the way the residual is read is dependent on something this means the decoder has to switch back and forth between reading bits and calculating sample values. These context switches can be rather expensive, especially when it messes with the CPU's branch prediction.

The encoder does not have this problem, because it already knows all sample values so it can defer writing bits until it is done creating a frame. I read something about Monkeys Audio having an adaptive predictor, so this explanation would make some sense at least.

TTA also has an adaptive predictor, I don't know about ALAC.

Quote
* In line with the previously posted results, WavPack -x4h and -x4hh decode faster (if only slightly so) than -h and -hh. Less data to wvunpack?
Considering WavPack's -x4 modes decompressing faster, @bryant was surprised so see that too. Because of that, I won't dare give an hypothesis :)
3
Lossless / Other Codecs / Re: Lossless codec comparison - part 3: CDDA (May '22)
Last post by Porcus -
Correction to my eyeballing:

TAK -p4m outcompresses Monkey's Insane - by 108 parts per million, that is such a small margin that had it been the other way around, it could maybe/maybe not be tilted by the already-published TAK 2.3.2.

Since I was too curious (and at the risk of posting wrong numbers - @ktf, are they correct?), here are the compression percentages around where we enter the LAnd of FROG:
50.39 OFR --preset 1
49.72 Monkey's Extra High
49.68 TAK -p4
49.66 OFR --preset 2 <-- default!
49.64 TAK -p4e
49.59 Monkey's Insane
49.58 TAK -p4m <-- 108 parts per million below Monkey's Insane
49.39 MPEG-4 ALS -7 <-- making ALS the highest-compressing ffmpeg-decodable codec
48.58 OFR --preset 3 <-- this isn't in line with eyeballing the plot vs ALS -7. Triangles vs circles seem to make for an optical illusion here, or did I get the numbers wrong?

The corpus this time is quite different, obviously. I'd be surprised if a "popularity-weighted" compression ratio is 0.5.
5
3rd Party Plugins - (fb2k) / Re: JScript Panel
Last post by marc2k3 -
I've been setting a bad example in my own scripts by not checking the src width/height before drawing but the only way that could happen was if they were calculated from the panel width/height which would have to be zero and therefore not visible. Default UI won't even let you resize that low but I guess it's possible with Columns/Panel Stack Splitter.

Setting these args as zero when the panel has proper dimensions and is visible is just really stupid. If calling the function succeeded, what exactly do you expect to see??

I really hate doing it but I've updated the function to silently bail if the src w/h are bad,

https://github.com/marc2k3/jscript-panel/releases

edit: the difference in behaviour between v3 and previous versions is because I'm using Direct2D instead of Gdiplus. Gdiplus was generally very tolerant of bad args everywhere but it seems more care is needed now. I already have special conditions in place where drawing text isn't even attempted if the width/height are less than 12px. I discovered this quite early on in my testing!
7
General - (fb2k) / Re: I moved computers. How do I get my original foobar2000 customized interface?
Last post by Porcus -
https://hydrogenaud.io/index.php?topic=99181.0

After an install on the new computer, you can try to copy the c:\program files (x86)\foobar2000 folder and the %appdata%\foobar2000 folder over to the new computer. For the latter, you can either access it from within foobar2000 by Alt+Shift+F b - or from the OS by presseing the windows logo key, typing %appdata% and hitting enter.

At worst you will have to delete stuff from your new computer and try over.
8
General - (fb2k) / I moved computers. How do I get my original foobar2000 customized interface?
Last post by kvhpkh -
 I recently moved into a different computer and even though I backed up all of my foobar2000 files, the external hard drive will not copy programs to the new computer.  I'm told this is a Windows thing.  So, my foobar2000 is not customized to the way that I had it.  Is there a way to retrieve that?  Is it stored in the cloud somewhere?  Or, what is the name of the folder/file that keeps that information?
10
Lossless / Other Codecs / Re: Lossless codec comparison - part 3: CDDA (May '22)
Last post by rompel -
You are right, I could have made that more clear. The software used for timing returns two values: CPU time and real time (wall clock time). These always differ by a little, I'm not sure how it is possible the wall clock time is sometimes shorter than the CPU-time, I guess that it is caused by some inaccuracy of the timing method.
Thanks, that makes sense.