As far as I'm concerned, those builds should be plenty fine and can be called "stable".
There are further patches on the dev branch (Case's reworked progress printing, improved help messages, some safeguards against negative array indices in the encoder math), but nothing that invalidates the current builds.
edit: For those wondering why the dev branch isn't yet merged to the main/stable branch: I'm still trying to figure out why *downsampling* doesn't appear to work (in either main or dev). For instance, when requesting downsampling a 44.1 kHz input file to 32 kHz (hmp3 -A32000 test.wav test.mp3), the encoder goes haywire and crashes/segfaults. That's because when computing some array indices in l3math.c, the indices can get negative (the dev-branch guards against those negative array indices). However, that's most likely because the encoder is fed invalid audio data (with the negative-indices guards in place, I get silent mp3 files) and I haven't properly investigated out what's going on there.
Would also be nice to have an easy way to show LUFS Integrated and Max LUFS M and Max LUFS S for each track.Here's an unpublished True Peak Scanner version with max momentary loudness (LUFS-M) and max short-term loudness (LUFS-S) scanning support: https://foobar.hyv.fi/foo_truepeak_0.6.8.fb2k-component.
At the moment the component defaults to storing LUFS-M in a tag field "truepeak_scanner_max_lufs_m" and LUFS-S respectively in "truepeak_scanner_max_lufs_s". If there are tag fields already in use by some software I'd happily change to use the same fields.
LUFS-I is computable from the ReplayGain value, but if there's strong will for yet another option, it could be stored in a separate tag field.
Here's an unpublished True Peak Scanner version with max momentary loudness (LUFS-M) and max short-term loudness (LUFS-S) scanning support: https://foobar.hyv.fi/foo_truepeak_0.6.8.fb2k-component.
At the moment the component defaults to storing LUFS-M in a tag field "truepeak_scanner_max_lufs_m" and LUFS-S respectively in "truepeak_scanner_max_lufs_s". If there are tag fields already in use by some software I'd happily change to use the same fields.
LUFS-I is computable from the ReplayGain value, but if there's strong will for yet another option, it could be stored in a separate tag field.
Would also be nice to have an easy way to show LUFS Integrated and Max LUFS M and Max LUFS S for each track.Here's an unpublished True Peak Scanner version with max momentary loudness (LUFS-M) and max short-term loudness (LUFS-S) scanning support: https://foobar.hyv.fi/foo_truepeak_0.6.8.fb2k-component.
You need avisynth script like this:Code: [Select]FL = WavSource("FL.wav")
FR = WavSource("FR.Wav")
:
SR = WavSource("SR.Wav")
MergeChannels(FL, FR, ..., SR)
You have to give channles to MergeChannels() in correct (WAV) order, and also tell qaac channel layout with the following option.Code: [Select]--chanmask=0x63f
ffmpeg -i blabla_SL.wav -i blabla2_SR.wav -i blabla3_SC.wav
Most values were the same, peak timestamp if different, along with track and album peak. Is this to be expeced?Peaks being slightly different is expected with different resamplers. Highest peak position changing entirely was unexpected, I have never noticed that happening. Would be curious to see what goes on in the track in those positions that causes such shift.
You didn't mess up anything as long as you didn't include the quotation marks when you typed the preferred resampler name in advanced preferences. As Defender said, that's step is no longer needed for True Peak Scanner component but now that you have done it, all components that ask for (random) resampler will get SoX. That's good, so all components will get a very fast and high quality option.