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
3rd Party Plugins - (fb2k) / Re: Biography Discussion
Last post by FritzLn -
I've noticed that the plugin doesn't seem to handle certain special characters correctly.

For instance, i get the following error in my console when attempting to retrieve the album review for: https://www.allmusic.com/album/closure-continuation-mw0003617672

Quote
Biography Server: allmusic review: Closure/Continuation / Porcupine Tree: not found

Is there a workaround or is this a bug? I'd create a github issue, but there doesn't appear to be a way to do it.
4
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by ngs428 -
Quote from: Case on
Quote from: ngs428 on
Quote from: Case on
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.

Example results:
Code: [Select]
True Peak Scanning track: G:\Music\Lossless\Metallica\(2008) Death Magnetic\05. All Nightmare Long.flac
Oversampling to 352800 Hz with Resampler (SoX)
Clip stats: ch0: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 16.0000000 (0:00.000 s), total clipping samples: 377258 (0:01.069 s)
Clip stats: ch1: peak: 1.2273319 (1.7792406 dB), pos: 0:19.988, max clip rms: 1.0105605 dB, pos: 1:01.660, max consecutive clipping samples: 17.0000000 (0:00.000 s), total clipping samples: 781139 (0:02.214 s)
Clip stats track:: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 17 (0:00.000 s), total clipping: 1158397 (0:03.283 s)
Clip histogram:
peak at 0.0 - 0.1 dB: 1038987 samples (89.69 %)
peak at 0.1 - 0.2 dB: 78387 samples (6.77 %)
peak at 0.2 - 0.3 dB: 21630 samples (1.87 %)
peak at 0.3 - 0.4 dB: 8597 samples (0.74 %)
peak at 0.4 - 0.5 dB: 4253 samples (0.37 %)
peak at 0.5 - 0.6 dB: 2362 samples (0.20 %)
peak at 0.6 - 0.7 dB: 1473 samples (0.13 %)
peak at 0.7 - 0.8 dB: 910 samples (0.08 %)
peak at 0.8 - 0.9 dB: 605 samples (0.05 %)
peak at 0.9 - 1.0 dB: 394 samples (0.03 %)
peak at 1.0 - 1.1 dB: 293 samples (0.03 %)
peak at 1.1 - 1.2 dB: 188 samples (0.02 %)
peak at 1.2 - 1.3 dB: 138 samples (0.01 %)
peak at 1.3 - 1.4 dB: 76 samples (0.01 %)
peak at 1.4 - 1.5 dB: 49 samples (0.00 %)
peak at 1.5 - 1.6 dB: 23 samples (0.00 %)
peak at 1.6 - 1.7 dB: 13 samples (0.00 %)
peak at 1.7 - 1.8 dB: 5 samples (0.00 %)
peak at 1.8 - 1.9 dB: 4 samples (0.00 %)
peak at 2.0 - 2.1 dB: 4 samples (0.00 %)
peak at 2.1 - 2.2 dB: 3 samples (0.00 %)
peak at 2.2 - 2.3 dB: 2 samples (0.00 %)
peak at 1.9 - 2.0 dB: 1 samples (0.00 %)

I think you are on to something.  How granular the histogram has to be is a good question.  Do we need it by 0.1?  Is sure does show that your file have a ton of clips, but approx 90% are 0.1 or lower.  I think this helps explain the impact of the clip result.

Example results:
Code: [Select]
Oversampling to 192000 Hz with Resampler (SoX)
Clip stats: ch0: peak: 1.0216434 (0.1859869 dB), pos: 0:34.500, max clip rms: -0.0615525 dB, pos: 0:32.646, max consecutive clipping samples: 1.0000000 (0:00.000 s), total clipping samples: 3 (0:00.000 s)
Clip stats: ch1: peak: 1.0251275 (0.2155575 dB), pos: 0:34.500, max clip rms: -0.0170493 dB, pos: 0:26.200, max consecutive clipping samples: 1.0000000 (0:00.000 s), total clipping samples: 2 (0:00.000 s)
Clip stats track:: peak: 1.0251275 (0.2155575 dB), pos: 0:34.500, max clip rms: -0.0170493 dB, pos: 0:26.200, max consecutive clipping samples: 1 (0:00.000 s), total clipping: 5 (0:00.000 s)
Clip histogram:
peak at 0.0 - 0.1 dB: 2 samples (40.00 %)
peak at 0.1 - 0.2 dB: 2 samples (40.00 %)
peak at 0.2 - 0.3 dB: 1 samples (20.00 %)
True Peaks calculated in: 0:01.280, speed: 31.15x

How this is presented is another story.  You can't write 20 tag values for this..  Output .txt file?  That would get to be a lot of data.  I like what you have here.  Thanks for spending time on it. 


I see you are Oversampling to 352800.  I left mine at the default of 192000.  Higher the more accurate and most of my files are 44100, so I could probably look to change it to 352800....  Factor of 8.  I thought it would pick an even factor when oversampling.  My 44.1k resampled to 192k.
5
Other Lossy Codecs / Re: Quite OK Audio (QOA)... anyone ?
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.

6
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by Case -
Quote from: ngs428 on
Quote from: Case on
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.

Example results:
Code: [Select]
True Peak Scanning track: G:\Music\Lossless\Metallica\(2008) Death Magnetic\05. All Nightmare Long.flac
Oversampling to 352800 Hz with Resampler (SoX)
Clip stats: ch0: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 16.0000000 (0:00.000 s), total clipping samples: 377258 (0:01.069 s)
Clip stats: ch1: peak: 1.2273319 (1.7792406 dB), pos: 0:19.988, max clip rms: 1.0105605 dB, pos: 1:01.660, max consecutive clipping samples: 17.0000000 (0:00.000 s), total clipping samples: 781139 (0:02.214 s)
Clip stats track:: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 17 (0:00.000 s), total clipping: 1158397 (0:03.283 s)
Clip histogram:
peak at 0.0 - 0.1 dB: 1038987 samples (89.69 %)
peak at 0.1 - 0.2 dB: 78387 samples (6.77 %)
peak at 0.2 - 0.3 dB: 21630 samples (1.87 %)
peak at 0.3 - 0.4 dB: 8597 samples (0.74 %)
peak at 0.4 - 0.5 dB: 4253 samples (0.37 %)
peak at 0.5 - 0.6 dB: 2362 samples (0.20 %)
peak at 0.6 - 0.7 dB: 1473 samples (0.13 %)
peak at 0.7 - 0.8 dB: 910 samples (0.08 %)
peak at 0.8 - 0.9 dB: 605 samples (0.05 %)
peak at 0.9 - 1.0 dB: 394 samples (0.03 %)
peak at 1.0 - 1.1 dB: 293 samples (0.03 %)
peak at 1.1 - 1.2 dB: 188 samples (0.02 %)
peak at 1.2 - 1.3 dB: 138 samples (0.01 %)
peak at 1.3 - 1.4 dB: 76 samples (0.01 %)
peak at 1.4 - 1.5 dB: 49 samples (0.00 %)
peak at 1.5 - 1.6 dB: 23 samples (0.00 %)
peak at 1.6 - 1.7 dB: 13 samples (0.00 %)
peak at 1.7 - 1.8 dB: 5 samples (0.00 %)
peak at 1.8 - 1.9 dB: 4 samples (0.00 %)
peak at 2.0 - 2.1 dB: 4 samples (0.00 %)
peak at 2.1 - 2.2 dB: 3 samples (0.00 %)
peak at 2.2 - 2.3 dB: 2 samples (0.00 %)
peak at 1.9 - 2.0 dB: 1 samples (0.00 %)
7
Lossless / Other Codecs / Re: HALAC (High Availability Lossless Audio Compression)
Last post by Hakan Abbas -
Quote from: Porcus on
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.
8
3rd Party Plugins - (fb2k) / Re: NEW ESLyric v0.5 - an alternative lyric show component
Last post by ngs428 -
Quote from: sveakul on
Quote from: ngs428 on
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?
酷狗音乐 = lyrics.kugou.com
QQ音乐 = QQMusic
网易云音乐 = music.163.com

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.

You can add Deezer if you can supply your own Deezer API key and cookie inside the script; from TT-ReBORN as posted to GitHub: https://github.com/ESLyric/feedback/files/13062122/eslyric_source_deezer.zip

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.

Changing the pref.image.cache.limit setting in Advanced to 1 prevents memory bloat (https://hydrogenaud.io/index.php/topic,122571.msg1042107.html#msg1042107)

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.