While it is readily acknowledged that lossyWAV is not particularly fast, it is what it is - and as each file need only be processed once, it's not the worst downside, IMO.You are right. For HALAC 0.2.9, I will add LossyWAV support even if it is simple for now.
How did you do lossyHALAC ...I do not have full information about the LossyWAV structure and I haven't fully examined. And I didn't do anything specifically for the content. I only disabled the prediction phase required for the lossless mode. However, I did not activate it for 0.2.8.
The LUFS-M and LUFS-S values were always calculated every 100 ms even when the option was disabled.That was pretty much my first thought.
I could make LUFS-M and LUFS-S faster by calculating them less often. But then their accuracy would be somewhat reduced. I don't know at all how often other tools update these values, to my knowledge LUFS-M and LUFS-S were originally meant for live monitoring.Exactly. Live monitoring you can see/do with foo_loudness_peakmeter.
I'd also like to see if I could utilize the Peter's ReplayGain scanner optimizations to speed up the libebur library, I believe there is a lot of room for improvement there.Always good to optimize.
Sorry for being a bit slow tonight, but is your response above saying that foo_out_spatial incorporates normal multichannel support (like foo_out_xaudio2 once included Spatial Output capability), and foo_out_xaudio2 is therefore not needed?XAudio2 output is a entirely different, it for example will happily take up-to 64 channel input. It may not play such audio correctly as there are no defined channel mappings for these, but at least it will audibly play something. And I already replied earlier that it could be useful for Wine people who want to try to avoid resampling.
So it's also a whole different API as well?Yeah, there are plenty of different ways to play audio on Windows.
What happens when I use this output, but I have the Windows spatial audio feature disabled?
400 ms (or 0.4 seconds) and 3000 ms (or 3 seconds) are correct. I'd just like to emphasise that the shown values are the highest readings recorded inside the track. Currently values are checked every 100 ms.
- Track and Album Max LUFS-M - Momentary (0.4 seconds?) measurement, as opposed to "I" which is the whole song
- Track and Album Max LUFS-S - Short Term (3 seconds?) measurement, as opposed to "I" which is the whole song
The foobar2000's ReplayGain scanner in EBU mode has always calculated LUFS-I value, it is just converted into ReplayGain's format with a simple formula. Nothing has changed in ReplayGain or its behavior. I just added ability to show and tag this field for people who want to see it.
- Track and Album LUFS-I - Similar to RG. Measures the entire song. How can I apply this value to normalize song's loudness levels? When I use Case's ReplayGain DSP, does it use this value? I can pick a loudness target of -14 LUFS, -18 LUFS, etc, but that is just the target. What value is is using to match the target? Is it still using the track and album gain or is it actually using the LUFS-I value, or does it matter?
@mzso - I created a Spatial Audio output component that Microsoft shouldn't be able to sabotage to stop working: https://foobar.hyv.fi/?view=foo_out_spatial.Nice. I can confirm it works with Windows Sonic. With stereo sources as well.
Very fresh out of the oven but at least it plays audio.
The Spatial Output component is completely independent output, it doesn't need anything else. It's a lot like WASAPI output except spatial mixer seems to have a fixed mixing rate independent of Windows mixer.So it's also a whole different API as well?
I think he clearly says that this is completely separate. The "spatial output" came from windows, but it got broken with the plugin.The Spatial Output component is completely independent output, it doesn't need anything else. It's a lot like WASAPI output except spatial mixer seems to have a fixed mixing rate independent of Windows mixer.Sorry for being a bit slow tonight, but is your response above saying that foo_out_spatial incorporates normal multichannel support (like foo_out_xaudio2 once included Spatial Output capability), and foo_out_xaudio2 is therefore not needed?
could you please consider implementing PLR in your scanner. Recently you have incorporated LUFS so now PLR is the last thing we have to calculate with enormously long formula and it does not go to tags.Added in version 0.6.9.
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.I had actually introduced a very silly bug when I created a helper class for handling the libebur128 performed scans. The LUFS-M and LUFS-S values were always calculated every 100 ms even when the option was disabled. That is now fixed in version 0.6.9.
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?
The Spatial Output component is completely independent output, it doesn't need anything else. It's a lot like WASAPI output except spatial mixer seems to have a fixed mixing rate independent of Windows mixer.Sorry for being a bit slow tonight, but is your response above saying that foo_out_spatial incorporates normal multichannel support (like foo_out_xaudio2 once included Spatial Output capability), and foo_out_xaudio2 is therefore not needed?