New version released with the promised change. Fast DSP reset will no longer be a problem.

Let me re-check why my 2.1 VU is showing lower value compared with my 2.0 VU. Hmm....

That's correct! If you mix down from **L+R to C** and then attempt to upmix from **C to L+R**, you **won't get back the original level**. Here's why:

### Mixing down L+R to C:
When you mix down the left (L) and right (R) channels to the center (C) using the formula:
\[
C = \frac{L + R}{2}
\]
You're averaging the two channels, which means the center channel (C) will have less energy than the sum of L and R. Specifically, if the left and right channels are at the same level, the center channel will have 6 dB less power than the original L+R sum because you're averaging the signal.

### Upmixing from C to L+R:
When you try to upmix from C to L+R with:
\[
L = C \times 0.5
\]
\[
R = C \times 0.5
\]
You're simply splitting the center signal evenly between the left and right channels. Since you averaged the L+R to create C initially, you're now redistributing that average back into the left and right channels, which results in a signal that’s at a lower level than the original L+R mix.

### Why this happens:
- **Loss in level during mixdown**: When you mix down L+R to C, you average the two channels, which results in a lower overall level.
- **Loss in level during upmix**: When you upmix C to L+R, you're redistributing the lower-level center signal back into both channels.

### The result:
When you mix down L+R to C and then upmix from C to L+R, you'll have a **reduced level** compared to the original L+R mix. Specifically, the upmixed signal will be approximately **6 dB quieter** than the original, assuming you used the simple upmixing formula (with equal distribution).

### How to avoid this:
If you need to preserve the original levels, you could modify the upmixing formula by compensating for the loss. For example, you could use:
\[
L = C \times \sqrt{2}
\]
\[
R = C \times \sqrt{2}
\]
This would restore the signal to its original level when upmixing. However, this might result in a slight imbalance depending on the exact method used for mixing down.

In practice, the exact compensation method can depend on the specific application and desired result, but the general rule is: **mixing down L+R to C reduces the level, and upmixing doesn't fully recover it unless you apply some compensation.**

MAC 11.0 normal -threads=1 -> 394,231,260
Encoding 21.910 s, Decoding 22.489 s

MAC 11.0 normal -threads=8 -> 394,231,260
Encoding 6.439 s, Decoding 7.149 s

HALAC 0.3.8 -normal -> 404,597,742
Encoding 3.150 s, Decoding 4.239 s

HALAC 0.3.8 -normal -mt=8 -> 404,597,742
Encoding 1.758 s, Decoding 1.999 s

Options looked into so far:

• MP3, AAC with icy-metadata
  Very limited metadata capabilities, there does not appear to be any official specification of the icy-metadata protocol despite being in mainstream use for over 20 years. No metadata beyond artist - title, no proper delimiting of these two, unspecified character encoding (though everyone seems to have finally agreed to send UTF-8 by now). Some radio stations even transmit album cover picture links.
• Ogg Vorbis
  Historically the first format to get of this stuff right, by sending new Vorbis stream headers with each new song. Sadly seems to be dying out.
• Opus
  Technically possible to send live info as with Vorbis, but nobody seems to do actually it?
• FLAC
  Live metadata capability missing, libFLAC won't decode concatenated FLAC files with new metadata.
• Ogg FLAC
  Live metadata capability missing, libFLAC won't decode concatenated Ogg FLAC files with new metadata.
  EDIT: libFLAC 1.5.0 can decode chained Ogg streams, this looks like the most promising option so far.
  Certain radio station uses Ogg FLAC with icy-metadata, which is a horrible idea but works.