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.
Last post by marc2k3 -
I was too lazy to find/test atomicparsley but have tested it just now. The windows version really does not write performer - this matches the docs. I guess the mac version is different in this regard.
Even the picard UI does not show performer where it clearly does for mp3.
Obviously this is not a reason for fb2k not to read it. I guess you'll have to see if the dev notices this thread.
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.
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.
Last post by ongaku -
Another problem with file operations: after restarting my Mac the external disk containing my music is mounted with a new file system UUID. And then file operations doesn't work anymore because the path contains the old UUID:
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:
[----] 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:
[----] 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".
Last post by yetanotherid -
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.
As in the Codepen project " Spectrum analyzer and spectrogram using custom FFT ", the first graph is as it is but the second one is exactly the same as one but flipped (looking at "negative" frequencies) in FFT bin index ordering
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.