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
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Hakan Abbas -
If the "k" parameter can be identified as adaptive in Rice coding, the block size is not important. Of course, this will also reduce the transaction speed. However, if the "k" parameter per block is to be determined, it is useful to be small against changes.

On the other hand, neither too small nor too large blocks for other statistical entropy encoders (Huffman, Arithmetic Coding or ANS) do not usually do good results. Of course, I'm talking about "-order 0". Because there is an additional load for each block. That is, it is more than Rice coding. It also reduces the process speed. If larger blocks are selected, the alphabet may grow this time (there may be an increase in the number of symbols). In other words, the distortion in the distribution may become more uniform, which is not desired.

This is the case for HALAC for now. 4096 samples in -normal mode and 8192/16384 samples are used in -fast mode. It may also be in any size, provided that it does not exaggerate. Statistical entropy encoders are not very efficient on audio data, contrary to popular belief. It is not easy to make it efficient. This means an extra processing load.

I don't share the results of the things I don't normally complete, but I tried to roughly show the difference between the following Rice coding (my own implementation) and the ANS coding. The Rice parameter was calculated very simple. Even if the situation does not change in terms of speed, this is not valid for all kinds of audio data in terms of compression rate.

Code: [Select]
BUSTA RHYMES(i7 3770k, 20 tracks, Total 829,962,880 bytes)
HALAC NORMAL 1 Thread (ANS) : 4.32 sec, 574,161,601 bytes
HALAC NORMAL 1 Thread (RICE): 3.66 sec, 567,469,774 bytes
2
Support - (fb2k) / Re: DUI panel for displaying dynamic info with title formatting?
Last post by pqyt -
Quote from: yetanotherid on
There's Text Display, but it only comes in a 32 bit flavor.
https://www.foobar2000.org/components/view/foo_textdisplay.
If/when at some point in the future, 32 bit foobar2000 ceases to be a thing, I'm definitely going to miss the Text Display UI element.
Thx. I'll see if I can create a clone that works on x64. AKAICT there is no source code available.
4
Support - (fb2k) / Re: Unexpected Behaviour with Multi-Value Performer Tag in M4A Files
Last post by ongaku -
That's not my experience. Picard writes performer tags to my M4A files, even if that is not advertised in their mapping table. The atoms are there as the output from AtomicParsley in my initial post shows.

But I checked the files now with another tool, mp4dump, and I can finally see why this discrepancy arises. Picard only writes one PERFOMER tag with one data element per value:

Code: [Select]
        [----] size=8+173
          [mean] size=8+20
            value = com.apple.iTunes
          [name] size=8+13
            value = PERFORMER
          [data] size=8+33
            type = 1
            lang = 0
            value = London Symphony Orchestra
          [data] size=8+26
            type = 1
            lang = 0
            value = Trinity Boys Choir
          [data] size=8+21
            type = 1
            lang = 0
            value = London Voices
          [data] size=8+12
            type = 1
            lang = 0
            value = Test

Whereas foobar2000 writes an individual PERFORMER tag per value:

Code: [Select]
        [----] size=8+90
          [mean] size=8+20
            value = com.apple.iTunes
          [name] size=8+13
            value = PERFORMER
          [data] size=8+33
            type = 1
            lang = 0
            value = London Symphony Orchestra
        [----] size=8+83
          [mean] size=8+20
            value = com.apple.iTunes
          [name] size=8+13
            value = PERFORMER
          [data] size=8+26
            type = 1
            lang = 0
            value = Trinity Boys Choir
        [----] size=8+78
          [mean] size=8+20
            value = com.apple.iTunes
          [name] size=8+13
            value = PERFORMER
          [data] size=8+21
            type = 1
            lang = 0
            value = London Voices

It would be nice if foobar2000 could read Picard-tagged files as-is with regards to PERFORMER, but it seems like Picard is doing it "wrong".
8
3rd Party Plugins - (fb2k) / Re: foo_upnp
Last post by GregHouse -
Hi.
How do I use "Stream Capture" to generate an "HTTP Stream" link without needing to select a renderer in the "UPnP Controller"?
This link I will add to HQPlayer Desktop.
9
3rd Party Plugins - (fb2k) / Re: Cannot install input_sacd component (foobar 1.15.11 - Win XP)
Last post by dragonxxx -
Hi everybody, thanks for many useful replies. And that was fast !! Here is my (slow) follow-up.
(I know about new foobar 1.5.12 and SSE2 problems, I didn't have time to try this.)

I went to a 64bits computer to test foobar 1.5.11 and input_sacd component. OS is still WinXP 32bits.
In my initial message I wrote "foobar 1.15.11" it was a typo.
The processor is AMD Socket 754 3300+ single-core SSE2 support 64bits CPU. I installed foobar 1.5.11;
for the input_sacd component I took "foo_input_sacd-1.1.3" as it is WinXP compatible. And it works.
The 2 components in "foo_input_sacd-1.1.3" were installed without probems, no crash or whatever.
I played a .DSF file from a SACD, then I loaded a SACD .iso file, immediately the tracks appeared in the
playing list. Now I have to learn how to extract FLAC files from the .iso

I read the comments of users, here is some history info:
All AMD 32bits processors in the Athlon XP family have SSE, including el-cheapo Duron that was not
that cheap after all. Semprons came at the end of the 32bits era for AMD, I would say they were SSE.
Then maybe AMD desactivated the floating point unit in these Semprons, if so it would be their
1xxx th. marketing strategy flop. At the beginning of the 64bits era for AMD all processors were SSE2;
a 64bits Sempron appeared as SSE2 but the last iteration was SSE3 (I have some of these).

I will be 72 at the end of this month. I saw the beginning of personal computing, the first IBM XT
computer, I bought an Apple II+ in 1983 etc. What a ride it has been !!
Now I stop to write and I am going to test foobar 1.5.12.