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
General - (fb2k) / Re: ReFacets
Last post by JohnBuckWLD -
Quote from: Scaramouche on
...I painfully miss the album art display from old facets component.
Quote from: Montchenot on
...Hope you're planning to replicate the "Display/Album art (no labels)" feature of Facets - it was really great for a plain, fast grid...(a) custom drop-down lists to be filled from values in tags, such as genre or composer. Much like a Facets column but in a combo box - This would allow for a greater grid of album images.
Quote from: Air KEN on
@Montchenot...i agree...
Quote from: ejp2472 on
...I agree with missing the "Display/Album art (no labels)" functionality...
Quote from: zpoison on
Black is nice but no album art in facets is much much worse than gray bars...
Quote from: DJ FRANK G. on
...The only thing I'm still missing in ReFacets is a cover view
Quote from: InchPerfect on
...Gentle reminder from Reddit...It would be so good to have album art back in ReFacets ...
In the micro, a lot of people have referred to facets' 1.0 images as "cover art" or "album art", where in fact, the art display was one of five display options: (1) cover front, (2) cover back, (3) disc, (4) artist, and (5) icon. In the macro, if/when implemented, it should also lessen the need for the abandoned ESPlaylist
3
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by Porcus -
Ah, OK. So it could be in the code and it could be done at compile time - meaning that some builds might potentially behave different? Or maybe not. Anyway, problem "solved" ...

... except for those who might think that hey, if they are willing to consider a different lossless codec than FLAC, then non-subset FLAC is at least as compatible maybe?  O:)
4
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by ktf -
I don't know how to explain this in simple terms, but let's say that for each order up to and including 12, there is code optimized for that specific order. For orders above 12, there is generic code.

A compiler can optimize loops in code much better if it knows in advance how often that loop will be traversed. It can 'unroll' a loop. In the generic code, the CPU will have to check after each addition and/or multiplication whether it needs to do another one for this sample, or whether it can move on to the next sample. When a loop is unrolled, there are simply a number of additions and multiplications after one another before encountering a check.

So, generic code looks like this:
Code: [Select]
repeat the following code for each sample {
     repeat the following code for each order {
          do multiplication
          do addition
     }
}

In FLAC, this is unrolled for orders below 12 to the following.
Code: [Select]
[...]
Use this code for order 2:
repeat the following code for each sample {
     do multiplication
     do addition
     do multiplication
     do addition
}

Use this code for order 3:
repeat the following code for each sample {
     do multiplication
     do addition
     do multiplication
     do addition
     do multiplication
     do addition
}

Use this code for order 4:
repeat the following code for each sample {
     do multiplication
     do addition
     do multiplication
     do addition
     do multiplication
     do addition
     do multiplication
     do addition
}

This is pretty much what happens for residual calculation, strictly up to order 12. This is the change you're seeing for the red line, because when using -p the residual calculation code dominates the execution time. Just look at the code here: https://github.com/xiph/flac/blob/master/src/libFLAC/lpc.c#L1101

For the blue line, the change between 15 and 16, is a little bit more complicated. This has to do with the autocorrelation calculation, which can be optimized in groups of 4, more or less. So, there is code for order below 8, below 12 and below 16. You see this with the red line, because when not using -p (or -e) the autocorrelation calculation dominates the execution time. Look at the code here: https://github.com/xiph/flac/blob/68f605bd281a37890ed696555a52c6180457164f/src/libFLAC/lpc.c#L158