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 Porcus -
First, QOA wasn't constructed to be transparent. It was intended to be "Quite OK" at very light decoding load. But I guess you know.
"Obviously" such a quantization calls for a noise shaping algorithm. How to round off each sample residual to one of the values implied by the dequant table. Given that the format has been published and frozen - a decoder has found its way into ffmpeg too - then if you want a revision you probably need to (I) give a case for the need for it and (II) what does actually improve. For (I), not only "but it could sound better" but also why that cannot be solved by noise shaping upon encoding; for (II), not only "I want another bit in the dequant table and I'm willing to reduce the 8 bytes slice coverage to only 15 samples", but what values for the new table.
Would you be interested in more statistics in the output? Just knowing that samples clip doesn't yet tell how bad it is. Exceeding the full scale by 0.1 dB would not matter at all, but exceeding it by 3 dB could be a problem. I could for example log how large percentage of clipping exceeded full scale by 1 dB, how much by 2 dB, etc.
After reading this, it got me thinking of what the "Clipping Samples" or "Album Clipping" actually tells us. I have some tracks that show thousands of clips and I have only scanned a handful of tracks, are the clips only 0.1 dB over, hard to say... Understanding how far the clip exceeds full scale by % of clips makes sense. Similar to what you described. % clips >1dB, % clips >2dB, % clips >3dB, etc., would give a user an understating of the impact of the clipping.
I spent some time today to think about what kind of statistics to gather from clipping, here's an experimental implementation: https://foobar.hyv.fi/foo_truepeak_clip_report_testing.fb2k-component I hope people don't quote this link as the component will be nuked once testing is done, leaving quotes with bad links behind.
The new experimental statistics aren't shown on the result dialog or tagged, they are only printed to foobar's console. So it's best to test that with only one track.
Your first attempt at Rice improves more than a percent at compression and thirteen at speed? :-o
(IIRC, FLAC computes the Rice parameter as the average residual. It is close to optimal.)
Yes, there is acceleration in my experiments in any case. Especially in low entropy data, the efficiency of Rice coding decreases. The JPEG-LS image format also uses Rice encoding. And calculates the parameter "k" retrospectively with a certain average. I calculated it in a similar way. Of course, the smaller the block size, the more accurate "k" values can be obtained. But in this case, we also have a lot of side information. The adaptive method is better. I know you're doing a good job with my image compression studies. In this case, our work performance decreases significantly. For the most appropriate situation, this issue needs to be studied specifically.
I was putting off upgrading, but it wasn’t that bad. Not done yet. I have to mess around with ESLyric yet a bit. What are those lyric sources in Chinese writing? Can Deezer be added?
For Metallum and Minilyrics sources to use artist/title search instead of artist/album so they can be used with radio streams you need to add modified versions of them. I did two which are attached below, they go into foobar2000\profile\eslyric-data\scripts\searcher, select as needed instead of the supplied ones.
If you still have the "LyricsOnDemand" source it should be deleted--it was removed from the install last month due to memory leakage/not working status reported by TT-ReBORN.
Songlyrics and Metallum have the habit of preventing a search from continuing to following sources if they pass a certain message about having the song indexed but no lyrics; the workaround is to add the following entries to the "Lyric Processor" box:
That's all the ESLyric tips I have!
@sveakul moving your comments to the component's thread. I am attempting to add the Deezer source, I have the API, but where can I find a cookie for it? If I try to import the script as is it states "invalid or incompatible script file" see attached.
Also, you mentioned 网易云音乐 as being "music.163.com", is that not NetEase? Looks like they are one in the same. This one seems to return Chinese and English text like this....
[01:01.90]And all the things you do, [01:01.90]也因为我们共同的点滴
I see there is a NetEase English (synched) source avialable via online sources, that one works better for us English speakers.
Last post by Klymins -
Can anyone make a 4-bit variation of QOA? It's needed because 3-bit quality is sometimes not enough (especially for low sampling rates). I've tried to make it myself via ChatGPT but I got a garbage output. Also, contacting @phoboslab didn't help.
Last post by ktf -
I've taken a look at my browser history from a year ago, but I can't seem to find any. I may well have mixed things up: I found some stores that only offered WAV, perhaps I misremembered.