Skip to main content


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
WavPack / Re: -h as the new default mode
Last post by Porcus -
Decoding speed yeah. Does to a large extent measure CPU load, but note that compiler optimizations / instruction sets matter, and might sometimes just mean that parts of the process will go faster and hotter.

FLAC was constructed for ultra-light decoding. Look here:,82125.0.html for numbers on Rockbox devices, which would - to save battery - clock down and not go faster than necessary. FLAC is so "simple" at decoding that you can decode some samples by hand with pen and paper, and indeed if you look at the IETF draft, the appendix carries out decoding of minimal .flac files in detail. Latest at

A bit of history with all reservations for accuracy; bear in mind that WavPack the algorithm is older than both FLAC and Monkey's. (Indeed it inspired the creation of the latter.)
Monkey's and TTA are "symmetric", and so was WavPack (I think?) and OptimFROG in old days: you would decode using the encoding algorithm in reverse, taking the same time. Heavier compression? You had to fire more effort at it, in both directions.
I guess we were many who had the gut feeling that if hard drive space was the limiting factor, then you would need that. So Monkey's users could save $$s on hard drives and that codec had a heyday some twenty years ago. But when Monkey's introduced the "Insane" level, there were portable players that could play in principle play it, but not in real time. Meanwhile, FLAC would play at longer battery life than MP3.
Then came TAK. Asymmetric, somewhat heavier on CPU than FLAC, but compressed like Monkey's High (nearly by the tests performed then). TAK changed our perception of what was possible with an asymmetric codec.

Josh Coalson, the creator of FLAC, had a comparison of the codecs available then. This is the oldest version that has decoding times - when FROG had just become OptimFROG:
It should be noted that WavPack's fast mode was faster at version 3.97, both in encoding and decoding, than early FLAC. You can see that -5 didn't encode particularly fast at the time, but FLAC was to improve. Note, FLAC and Shorten (and in part some RKAU mode) did exhibit this big asymmetry between encoding time and decoding time.
Fast forward to 2007:

Now, what has happened since 2002? Except a few new ones?
* FLAC has become more efficient. Most recently also in the fastest encodings. But FLAC works as follows: try many possibilities and pick the best. None of them are heavy at decoding. And by trial and error one has found ways where FLAC can try fewer without having to do so much brute-forcing. You can put the reference encoder at work trying out > 1000 different parameter combinations (per frame) if you seriously want to see how low bang for the buck you can get.
* Among the "symmetric" codecs, both WavPack (the -x) and OptimFROG has gotten "extra encoding processing" which does some of the same: spend more effort on encoding without hurting decoding. But Monkey's has frozen its bitstream: given the signal and the mode (say "high"), the encoded bitstream is determined. Encode a CD with the newest Monkey's - it will be bit-identical to a 3.99 encode. TTA also has a bitstream determined uniquely by the audio - the only thing that could improve would be code optimization.
* We know more about compilers; build matters!,123025.msg1029768.html#msg1029768 .
* And CPU matters. When ktf recently switched his comparison studies from AMD to Intel, WavPack performance numbers suffered compared to FLAC. But meanwhile there was a test on Celeron, where all for sudden the fastest TAK mode would decode faster than FLAC.
* High resolution audio has started messing up what we "knew" from typical CD audio. Especially since a lot of "high resolution" has very little content in the top octaves or the lowest bits.
3rd Party Plugins - (fb2k) / Re: [fb2k v2] SQL Tree (foo_uie_sql_tree)
Last post by chrisdukes -
fbuser, you literally replied while I was writing this new post; awkward timing, but deeply appreciated none-the-less.  I made a bunch of changes since my last one, but I'm going to read your reply and see what changes I should make.

Multi-Genre Examples:
Code: [Select]
Track #1 Genre - Soundtrack; Score; Anime; Electronic
Track #2 Genre - Soundtrack; Score; Anime; Rock
Track #3 Genre - Soundtrack; Score; Movie; Jazz
Track #4 Genre - Soundtrack; Stage & Screen; Soul; Funk
Track #5 Genre - Soundtrack; Stage & Screen; Rock; Progressive

Ideally, it should look like this:
Code: [Select]
--Stage & Screen

The album sub-nodes would follow their respective genres.  Also, I have a genre field without split values and I have a genre_mv field with split multivalue tag checked.

If I use GROUP BY at the end of the query, it kind of looks like what I want (see screenshot) but I know I can't use GROUP BY because it will only return a single album for each genre_mv.

Code: [Select]
       [original album],
       [album artist],

FROM MediaLibrary
WHERE genre LIKE '%Score%' OR genre LIKE '%Stage & Screen%'

ORDER BY genre_mv

Code: [Select]
        WHEN genre LIKE '%Score%' THEN 'Score'
        WHEN genre LIKE '%Stage & Screen%' THEN 'Stage & Screen'
        END AS Category1,
        WHEN genre LIKE '%Score%' AND genre_mv IN ('Anime', 'Movie', 'Musical', 'Television', 'Video Game') THEN genre_mv
        WHEN genre LIKE '%Stage & Screen%' AND genre_mv NOT IN ('Soundtrack', 'Score', 'Stage & Screen') THEN genre_mv
        END AS Category2,

FROM tabletest
GROUP BY Category1, Category2;

I still a have a lot to learn about SQL so thanks for any help!
foobar2000 mobile / Re: [Skinning] Can compare current and next track title in the [label] element?
Last post by zeremy -

Code: [Select]

You seem to have missed $get


edit : but I see your point that you can't mix [fields] types in titleformatting and you can't mix [infosource] switching in the titleformat.
It just doesn't work..
3rd Party Plugins - (fb2k) / Re: [fb2k v2] SQL Tree (foo_uie_sql_tree)
Last post by fbuser -
Using multivalue splitting is the wrong approach here as it duplicates the rows of the result which leads to having an own node for each value of the column.

Instead you should first define a function to convert the multivalue column to a JSON array in the SQLite console:
Code: [Select]
SELECT define('mv2json','''["''||replace(coalesce(:v,''''),'' · '',''","'')||''"]''');

This function is persistent and therefore needs to be created only once. In case you defined an own multivalue separator for your genre column you need to replace this
Code: [Select]
... '' · '' ...

by this
Code: [Select]
... ''<your multivalue separator>'' ...

Afterwards you can define your query like this:

Code: [Select]
WITH Genres AS (
  SELECT mv2json(genre) genres
  FROM MediaLibrary
FROM Genres

Add as many columns as you need to cover the maximum numbers of values in your genre tag.

Finally, tick "Omit <null>" in the advanced tab.

I did not test it in detail, but it should work like this.
Lossless / Other Codecs / Re: FSLAC: A FLAC Backward-Compatible Free Semi-Lossless Audio Coder (NMR)
Last post by Kraeved -
The difference in size between FSLAC -2 and -3 never ceases to amaze me. But the hand still reaches for -3, because its spectrogram is almost indistinguishable from the original, which welcomes further lossy compression for the portable player. Of course, the spectrogram is not everything, you need to check with your ears, but it would still be unpleasant to upgrade the hardware tomorrow and discover that the -2 collection has flaws. Curiously, achieving the same visual indistinguishability with Wavpack in hybrid mode is not easy, it stubbornly retains some content (quantization noise, I guess) in the upper segment.

Boris Blank - Vertigo heroes (Part I) @ 48 kHz 24 bit
Code: [Select]
 9 651 738 =  345 kbps = out.fslac2.flac
11 655 366 =  416 kbps = out.b4x.wv
14 237 225 =  508 kbps = out.lossywav-high.flac
17 705 218 =  632 kbps = out.fslac3.flac
47 354 972 = 1691 kbps = out.flac
64 512 068 = out.wav

Diary of dreams - Viva la Bestia @ 44.1 kHz 24 bit
Code: [Select]
11 883 904 =  309 kbps = out.fslac2.flac
14 424 398 =  375 kbpx = out.b4x.wv
18 684 292 =  486 kbps = out.lossywav-high.flac
21 878 177 =  569 kbpx = out.fslac3.flac
63 806 211 = 1660 kbps = out.flac
81 359 276 = out.wav
Audio Hardware / Re: Electrostatic speaker myths
Last post by ktf -
Is there anyone present here who would take a stab at "debunking" this supposed critical weakness of cones, and thus advantage of ESLs?
Sure. I'll start with a simple omission in one of the statements:

"Interestingly and importantly, the way an ESL converts an audio signal to sound is the exact inverse of how a recording microphone converts sound into an audio signal. In a microphone, pressure creates voltage, and in an ESL, voltage creates pressure. This contributes to the exceptional accuracy of ESLs. It is not the case for cone speakers, where electrical current supplies non-linear force to a multiple spring-mass-damper system.
This ignores that electrostatic speaker membranes are usually rather large. Microphone membranes are often less than a centimeter (roughly half an inch) in diameter, and with larger membranes one often sees a roll-off in the high frequencies. The size of the membrane matters, so one cannot say an ESL is a direct inversion of a microphone.

More in general: Sure, electrodynamic speakers are not perfect. Tuning a mass-spring-damper system is a compromise, that is correct. But in return, electrostatic speakers are large and thus deviate from the ideal point-source. The lack of a crossover actually works against electrostatics in this respect: the higher the frequency, the more the size of the driver matters. So, a two-way speaker system can use a small element to come as close as possible to a point source for those high frequencies that need it the most, while using a larger driver for low frequencies that have long enough wavelengths for the size not to matter too much.

As with most technologies, there is compromise. Just because one technology outperforms the other in one aspect doesn't mean it is better, as it might be flawed in another.

Finally: Almost all nearfield studio monitors, which are built for the sound production with the highest accuracy, are electrodynamic, not electrostatic. That is not a coincidence. You could also say: the recording you're listening too has probably been approved by the musician while listening to an electrodynamic speaker. There is no reason to assume electrostatic loudspeakers will be closer to the artists intent if that artist worked on the recording using electrodynamic speakers.
Audio Hardware / Re: Electrostatic speaker myths
Last post by magicgoose -
What counts as loss of information? How much of it is too much?
If there is an imperfection that can be near perfectly negated by some equalization, is that also loss of information?
I would trust measurements more than intuitive reasoning. Are there any such measurements to back up this argument?
3rd Party Plugins - (fb2k) / Re: Text Display (foo_textdisplay)
Last post by marc2k3 -
If you tag your files with musicbrainz picard and enable whatever the settings are for performers/instruments, text display can display the contents of those tags.

Large caveat: fb2k doesn't support the TCMP/IPLS id3 frames Picard writes so if you have lots of mp3 files, you can kind of forget about that.

Online information can be fetched by this script for Spider Monkey Panel..

It's has zillions of options to play around with.

I have a component (JScript Panel 3 in signature) which is much more threadbare on the option front. But it is available for 64bit for those who are interested in that.

Some example scripts: