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
11
FLAC / Re: FLAC v1.4.x Performance Tests
Last post by Wombat -
I tried some AVX2 versions on my 5900x and metaflacs replaygain is clearly faster with GCC, 16bit and option disabled asm is clearly faster with GCC and 16bit/24bit combined is both faster with the default AVX2 clang.
All i was able to produce with lto and clang produced slower binaries.
I guess some experienced users can do better with lto or pgo or even a combination of both.
16
Other Lossy Codecs / Re: lossyWAV 1.4.2 Development (was 1.5.0)
Last post by Porcus -
Block size 512 can be set with

flac -b 512
wavpack --blocksize=512
Takc.exe -fsl512

Not much use trying ALAC as it doesn't support wasted bits, but if you want to experiment with block size: CUETools.ALACEnc.exe -b 512 (remember the whitespace). Also Monkey's doesn't support wasted bits.
17
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by Defender -
Because scanning with 0.6.8 seemed a lot slower than scanning with 0.6.7 and I was wondering if that was because of the extra LUFS-M/S scanning
[...]
Does this make any sense to you?
LUFS-M / LUFS-S scanning seems to be the reason. I use the libebur128 library for LRA scanning and also for LUFS-M/S. Seems that the extra work required to split the incoming data at precise 100 ms chunks to be fed to the library also hurts LRA scanning speed.
Can confirm that 0.6.8 with only RG+DR+POS enabled performs on the same level as 0.6.7 with RG+DR+POS+LRA.

Is your routine for calculating LUFS-S/M pretty much optimized already or do you expect to be able to implement some speedgains in the feature?

And second question: Would it be possible to use in 0.6.8+ the LRA method that was in use in 0.6.7 when scanning LUFS-S/M is not enabled?
18
Other Lossy Codecs / Re: lossyWAV 1.4.2 Development (was 1.5.0)
Last post by 2012 -
@Hakan Abbas

Nick meant passing -b 512 to flac encoder, which you didn't:

Code: [Select]
13,749,585 '01 Riot (Feat. Damian Jr. Gong Marley).lossy.flac'
11,713,235 '01 Riot (Feat. Damian Jr. Gong Marley).lossy.b512.flac'
15,951,686 '02 Entertainment 2.0 (Feat. Juicy J, 2 Chainz & Nicki Minaj).lossy.flac'
13,103,138 '02 Entertainment 2.0 (Feat. Juicy J, 2 Chainz & Nicki Minaj).lossy.b512.flac'
19
3rd Party Plugins - (fb2k) / Re: Dynamic Range plugin
Last post by omasciarotte -
Someone needs a simples dynamic range meter, with the ability to record a log file. + truepeak does not show rms and peak

Our DROffline and DROffline MkII are the two successors to the original TT-DR Offline from way back when. DROffline, now in version 2.2.2, is a modern version of the original. DROffline MkII includes all the original functionality plus BS.1770, PSR and the ability to handle FLAC and ALAC. You can find more info on the MAAT.digital website.

The original TT-DR Meter could not measure DRi, it could only estimate. DRMeter MkII can measure.
20
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by Case -
Because scanning with 0.6.8 seemed a lot slower than scanning with 0.6.7 and I was wondering if that was because of the extra LUFS-M/S scanning
[...]
Does this make any sense to you?
LUFS-M / LUFS-S scanning seems to be the reason. I use the libebur128 library for LRA scanning and also for LUFS-M/S. Seems that the extra work required to split the incoming data at precise 100 ms chunks to be fed to the library also hurts LRA scanning speed.