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
1
MP3 / Re: LAME -V3 vs -V4?
Last post by DVDdoug -
If you're not concerned about file size you can go with a "higher quality" setting, even V0 or 360kbps CBR.      But, we can't really say higher quality if we can't hear a difference.  

More compression (smaller files) is the only reason to choose a higher V-number.
2
General Audio / Re: Downsampling to 44.1 - integer vs non-integer ratio
Last post by kode54 -
What I meant was that the encoder is likely to produce the same output given the same input, regardless of the compiler used. Most integer operations are guaranteed a given precision.

No guarantees that a lossy encode will produce anything even close to the original, and any decoder you use could produce different output depending on the compilers.

I was referring to a fixed precision encoder producing fairly consistent results (compressed file) from the same input, regardless of the machine architecture used to compile or run the encoder. A fixed precision decoder should also produce consistent PCM output from the same lossy input data, regardless of the machine running it. No guarantees about round trip accuracy, though.
3
Lossless / Other Codecs / Re: Lossless codec comparison - part 3: CDDA (May '22)
Last post by TBeck -
Well, i just looked at the source code (i am a bit tired, errors likely), and it seems as if -7 translates to
-a
-b
 -l (Lsb check, wasted bits)
1023 (1024 ?) predictors
Frame size: 20480 samples (per channel)

What might be different ist the option -g, which is 0 by default and set to 5 (the possible maximum) by -7.

It is called 'Block Switching Level'. Once i knew what this meant. Not perfectly now, but i seem to remember that this controls, how hard the encoder evaluates if it is advantegous to split the frame into 2 or more sub frames with individual parameters e.g. predictors. With a frame size of 20480 it is definitely necessary to perform this to achieve good results beacuse the signal parameters are likely to change in 464 ms of audio data. I suppose, -g0 means "turn it off". A bad choice that can perfectly explain the comparitively bad performance of the second-highest setting.
4
Lossless / Other Codecs / Re: Lossless codec comparison - part 3: CDDA (May '22)
Last post by Porcus -
Mp4Als, because it is so similar to TAK, but can use up to 1024 predictors (if i remember this right) compared to TAK's 160. I found 16 files where Mp4Als is at least 0.5 percent stronger than TAK. In any case there is also a clear advantage of TAK's preset 4 over 3, which are using 160 vs. 80 predictors. Imho strong evidence that the advantage of Mp4Als is based upon the higher predictor count.

Yes, but TAK -p3 beats ALS' -a -b -o1023, where -o1023 is the predictor order ... or the max predictor order. That is the second-to-highest ALS setting used in the test.
So either the high prediction order is not the explanation - or, in case -o1023 only sets the maximum, it could be that ALS selects lower orders. The "-a" switch allows for adaptive predictor order, but I don't know how that matters.

It seems that the max framesize is 65536, Maybe that - in combination with the predictor order? -  is what makes the "-7" performance, both for good and bad?
5
MP3 / Re: LAME -V3 vs -V4?
Last post by Aleron Ives -
Since you're in charge of running your own ABX tests, you can easily improve the reliability of the results by only conducting tests when you're feeling alert. If you don't want to run your own tests, just use the recommended settings. Those are really the only two options. Nobody can tell you if V2 is overkill except you.
6
Lossless / Other Codecs / Re: Lossless codec comparison - part 3: CDDA (May '22)
Last post by TBeck -
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.
You are right, TAK does not by default.

BTW: I am so grateful for your work! It is invaluable to have a trustable external source to check my own findings against (danger of routine-blinded). And often inspirational. The same is true for member Porcus. Sorry if i don't reply more often. My bad english skills are a severe impediment. Could have written this text much better in german in 1/10 of the time.

Regarding the speed i would like to make one remark:

If the cpu of the test system really is an A4-5000: The most time consuming function in the encoder is performing lots of SSE2/SSSE3 multiplications. This particular cpu can start one each 2 clock cycles. But in between i am using the instruction palignr, which usually is very fast but on this cpu takes 19 clock cycles to execute. And since the next mutiplication has to wait for the result of palignr, you have only a fraction of the usual speed, about 1/3 to 1/2 i would estimate. This regards to this function, overall the effect is considerably smaller. The decoder is not affected.

On the other hand: Maybe other codecs are similarly affected. Who knows. But the risk of distortions of the speed results seems to be bigger if a non-mainstream or outdated cpu is used.

I wouldn't have mentioned it, but if we talk about speed variations of 30%, this possibly should be taken into account. The A4-5000 is one of the 2 cpus i know of where Taks optimizations don't work well. The other is the Pentium 4. TAK 2.3.3 (which will be released soon) will also drop some optimizations for the good old Core 2 Duo line. More exact: It will do some things in the way more recent cpus like better. I usually take mainstream cpus of the past 10 years into account.

Interpretation of the results

My quick analysis based upon looking at the diagrams, not at the data. I am particularly interested into the performance of Mp4Als and OptimFROG.

Mp4Als, because it is so similar to TAK, but can use up to 1024 predictors (if i remember this right) compared to TAK's 160. I found 16 files where Mp4Als is at least 0.5 percent stronger than TAK. In any case there is also a clear advantage of TAK's preset 4 over 3, which are using 160 vs. 80 predictors. Imho strong evidence that the advantage of Mp4Als is based upon the higher predictor count.

This means, that Tak should easily (in terms of programming effort) achieve similar results by simply increasing the predictor count (tried up to 512 some time ago). But this would definitely make encoding and decoding considerably slower. And i suppose that this file set is unusual high predictor order friendly. Maybe i will try what can be achieved by a moderately higher predictor count (256, 320 or 384).

OptimFROG obviously is the measure of all things (compression wise). I am long used to see it perform 1.5 to 2 percent better than TAK. I see two primary reasons for it's better performance:

1. It's using a different method (than TAK, FLAC and Mp4Als) to calculate the predictor coefficients, that is often advantegous.

2. It seems to take advantage of 'holes' in the sample frequency distribution, caused by amplification by a constant factor or non uniform quantization (12 bit DAT as source e.g.). This can have huge effects. I have seen savings of more than 10 percents!

Some speculation:

I suppose 5 files are affected by the second Factor, for instance "Alela Diane - The Pirate’s Gospel".

Pattern:

2 or more percent better than any other encoder including LA.
LA seems to be particularly important in this context, because it is usually close to the higher end of OptimfROGS graph. I suspect it is similar to OptimFROG regarding Factor 1, but lacks Factor 2.

Quite speculative. But feels right.
7
General - (fb2k) / Re: I moved computers. How do I get my original foobar2000 customized interface?
Last post by Porcus -
Don't delete the Roaming folder itself - it contains too much about other applications.
Delete the foobar2000 folder in the Roaming folder.

You might need to have Administrator privileges for the copying operations I described, as well as for deletion.
Hit the Windows key, type "cmd", select Run as administrator. Will open a command prompt. If you aren't fluent at command line, type "explorer" at the prompt and hit Enter. That should open an Explorer window with admin rights.
9
3rd Party Plugins - (fb2k) / Re: Biography Discussion
Last post by paregistrase -
I use the feature & in my case there are duplicates between the folders & I didn't want them merged. I checked a few discogs vs lfm ones and there seemed to be some duplication of images in those two sources as well. You can always merge them yourself into the lastfm download folder. I can understand you might not want to do that, but at least there is a solution. If you decide to try, I suggest using a back-up copy in case it doesn't work out.

The duplicates were one of the reason I want to merge them in the display, to be able to spot them and delete them.
I understand that it is not good to display duplicates to the general public.

Seems that I need to rethink my folder structure to artist pictures.

10
3rd Party Plugins - (fb2k) / Re: Biography Discussion
Last post by WilB -
@paregistrase

I'm glad you now have it sorted.

Quote
...possible to merge the artist photos

I use the feature & in my case there are duplicates between the folders & I didn't want them merged. I checked a few discogs vs lfm ones and there seemed to be some duplication of images in those two sources as well. You can always merge them yourself into the lastfm download folder. I can understand you might not want to do that, but at least there is a solution. If you decide to try, I suggest using a back-up copy in case it doesn't work out. Make sure 'Image Filter Lastfm' in panel properties is off else the discogs images won't display.

@pIv
isTrackRevAvail should be fixed in the next version

It's used to set the grayed status of "Track review" on the load menu.

Also fixed for the next version is a regression in set language.