This component has been obsoleted by the ReplayGain scanner bundled with foobar2000 version 1.1.6.I have produced a scanner interface almost entirely from scratch, based on [a href='index.php?showtopic=86116']libebur128[/a]. Basic information and a binary are posted here (http://www.foobar2000.org/components/view/foo_r128scan), and the full source is posted here (http://kode54.foobar2000.org/foo_r128scan_source.zip), but I warn you, it isn't pretty.
It writes -18 - LUFS to the normal ReplayGain track and album gain level tags, and optionally scans for the "true" peak by resampling the signal to 192KHz first, using the foobar2000 resampler service, but this is disabled by default because it has a pretty heavy speed cost.
No attempt is made to support reading or writing the EBU R128 "standard" of tags proposed in [a href='index.php?showtopic=85978']this topic[/a], because that is beyond the scope of a mere scanner component. The player core must first support representing that information internally with its binary ReplayGain information structures, and then every input component that supports reading and/or writing tags must be modified to support these changes.
Change log:
- Version 1.21 - 2011-02-07 14:12 UTC:
- Fixed a bug in libebur128 when handling weird sample rates.
- Version 1.20 - 2011-01-31 01:33 UTC:
- Fixed album scanning results reporting.
- Version 1.19 - 2011-01-31 01:22 UTC:
- Disabled apply tags button when there are no tags to apply results to.
- Version 1.18 - 2011-01-30 23:53 UTC:
- Implemented full error reporting.
- Version 1.17 - 2011-01-30 06:23 UTC:
- Fixed another crash issue with IO error handling in the scanner thread.
- Version 1.16 - 2011-01-30 05:28 UTC:
- Fixed a potential problem with threaded album scanning where not all of the threads would result in valid scanner instances.
- Version 1.15 - 2011-01-29 02:44 UTC:
- Updated to libebur128-0.1.9.
- Changed scanner function to reconfigure libebur128 instead of resampling or failing outright.
- Version 1.14 - 2011-01-28 05:48 UTC:
- Implemented proper track and album skipping.
- Version 1.13 - 2011-01-28 05:04 UTC:
- Implemented multi-threaded album scanning.
- Version 1.12 - 2011-01-27 07:04 UTC:
- Scanner status now only lists the files currently being scanned.
- Scanner status window now shows the count of processed files and the total count.
- Limited thread count by the number of jobs to execute.
- Version 1.11 - 2011-01-27 06:15 UTC:
- Fixed channel mapping setup for non-stereo files.
- Added an abort check to the scanner processing loop just in case.
- Changed the scanner results to a modeless dialog to get rid of the Windows 7 taskbar progress indicator artifact.
- Changed all applicable get_item() calls to [] operators.
- Version 1.10 - 2010-01-26 10:34 UTC:
- Changed the "true" peak scanner to always use an upsampling factor of 4 instead of a fixed sample rate of 192KHz.
- Version 1.9 - 2011-01-26 09:32 UTC:
- Fixed mixed up infinity/NaN in ebur128.cpp.
- Fixed rg_offset to return the correct invalid gain constant when the result is invalid or out of range.
- Version 1.8 - 2011-01-26 08:47 UTC:
- Implemented support for mid-file and mid-album sample rate changes.
- Version 1.7 - 2011-01-26 08:15 UTC:
- Fixed albums-by-tags scanning mode to include the last album detected in the batch.
- Disabled multi-threading in debug builds.
- Fixed "true" peak calculation to instantiate the resampler for more than just the first track in the album.
- Restructured "true" peak calculation resampler code to properly handle the last chunk produced by the decoder
- Version 1.6 - 2011-01-26 06:03 UTC:
- Implemented thread priority control.
- First public release.
- Version 1.5 - 2011-01-26 05:53 UTC:
- Implemented finer grained progress indicating.
- Version 1.4 - 2011-01-26 05:16 UTC:
- Fixed RG scanner result display dialog showing the track gain in the album peak column when scanning in track gain mode.
- Version 1.3 - 2011-01-26 05:16 UTC:
- Made "true" peak scanning optional.
- Version 1.2 - 2011-01-26 04:24 UTC:
- Fixed RG result info display when there are results from more than one job in the batch.
- Fixed RG scanner to remove the current job's track names and update the display on I/O error.
- Version 1.1 - 2011-01-26 03:45 UTC:
- Fixed RG info applying filter result finding function to actually return the item indices so that album set tags are written correctly.
- Version 1.0 - 2011-01-26 02:31 UTC:
- Album scan mode now keeps track of the sample rate and channel information across tracks.
- Version 0.0 - 2011-01-26 02:18 UTC:
Big thanks!
Bug report:
When I select N albums and use "Scan selection as albums (by tags)", it scans only first N-1 albums.
True peak scanning works only for the very 1st track.
Also, I think that resampling 44,1 and 88,2 to 174,6 kHz instead of 192 kHz should be a bit faster (especially for SoX resampler users )
Scan selection as albums (by tags) does not work for me. Please check.
EDIT: As I selected only one album, the mentioned operation does not work as also confirmed by lvqcl.
The component currently has difficulty dealing with albums that contain tracks with varying sampling rate. Also, it was updated just a few minutes ago to deal with lvgcl's problem. Could you verify that all tracks in your album are of the same sampling rate, please, thuan?
Yes they are
Updated.
Also, for one thing, the specification, or at least the weirdos in that R128GAIN topic, call for resampling to 192KHz for the peak measurement. And besides which, why does it matter for SoX resampler users? Does its resampler have some sort of speed optimization for even multiple upsampling?
Currently, I just use the core resampler_entry::g_create() function, which instantiates the first resampler service it can find that accepts the given source and target sample rates. The order in which it searches for resampler DSP services is linear, but the order in which loaded components' services appear is randomized on every startup, so there's no guarantee you'll be getting either foo_dsp_std's polyphase resampler, or SoX, or any other installed resampler. Well, unless you remove all DSP components which have resamplers, except for the one you want to use.
The source and target sample rate selection was only an issue back when foobar2000 still bundled a SSRC-based resampler. Now that it bundles a polyphase resampler that supports all rates, it will be selected automatically if it is the first resampler in the global services list.
Great work!
A few things that I noticed:
When adapting the return values of the library for C++, "0.0 / 0.0" should be "std::numeric_limits<double>::quiet_NaN()" and "-1.0 / 0.0" should be "-std::numeric_limits<double>::infinity()" (with a minus!).
Also, for RG tags one must limit the output values of the library when it returns -infinity (on silent tracks).
Fixed, thanks for the report.
Also, for one thing, the specification, or at least the weirdos in that R128GAIN topic, call for resampling to 192KHz for the peak measurement.
Here: http://www.hydrogenaudio.org/forums/index....st&p=738148 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=85978&view=findpost&p=738148)
4 × over-sampling
And besides which, why does it matter for SoX resampler users? Does its resampler have some sort of speed optimization for even multiple upsampling?
My tests on Core2 2,5GHz:
True Peak = Off: WAV 44,1k scanning is 420x realtime, WAV 48k is 400x realtime;
True Peak = On, PPHS: WAV 44,1k is 29x realtime, WAV 48k is 33x realtime;
True Peak = On, SoX: WAV 44,1k is 18x realtime, WAV 48k is 41x realtime.
True Peak calculation slows scanning severely (for no apparent benefits IMHO) but nevertheless 4x upsampling is faster.
there's no guarantee you'll be getting either foo_dsp_std's polyphase resampler, or SoX, or any other installed resampler.
According to my tests, fb2k never uses built-in PPHS resampler when there's another resampler with priority > 0.
Fine, I changed it to 4x upsampling. And yes, that feature is disabled by default for a reason.
Also, I didn't notice the priority checking in the resampler DSP enumeration. Ah, well. I guess SoX is programmed with a higher priority.
Hi, its me again. It doesn't work correctly with mono files: calculates only peak values, not gain.
True Peak = Off: WAV 44,1k scanning is 420x realtime, WAV 48k is 400x realtime;
True Peak = On, PPHS: WAV 44,1k is 29x realtime, WAV 48k is 33x realtime;
True Peak = On, SoX: WAV 44,1k is 18x realtime, WAV 48k is 41x realtime.
True Peak calculation slows scanning severely (for no apparent benefits IMHO) but nevertheless 4x upsampling is faster.
True Peak = Off: MP3 44,1k scanning is 524.17x realtime
True Peak = On: MP3 44,1k is 105.69x realtime
On AMD Phenom x6 1055T 2.8Ghz, 8GB RAM
Probably quadraphonic (FL, FR, BL, BR) files are affected too.
Simple patch: replace
for ( unsigned i = 0, j = 1; i < last_channels; i++, j <<= 1 )
{
int channel = EBUR128_UNUSED;
switch ( last_channel_config & j )
...
with
for (unsigned i = 0; i < last_channels; i++)
{
int channel = EBUR128_UNUSED;
switch ( audio_chunk::g_extract_channel_flag(last_channel_config, i) )
...
but this results in 3.01 dB difference between 'mono' and 'mono converted to stereo' files...
I think this means that ebur128_gated_loudness() function should be changed:
return ebur128_energy_to_loudness(gated_loudness * ( (st->channels==1 && st->channel_map[0]==EBUR128_CENTER) ? 2 : 1));
Added:
...But it's the player that maps center channel to left & right, so probably it should be done on player's side (or at least somewhere in foo_r128scan.cpp, not in ebur128.cpp) ?
"True peak" seems designed to try catch and prevent inter-sample clipping. I'm confident that most modern DACs are designed to handle this edge case anyhow. We shouldn't need to worry about it that much.
I have produced a scanner interface almost entirely from scratch, based on [a href='index.php?showtopic=86116']libebur128[/a]. Basic information and a binary are posted here (http://www.foobar2000.org/components/view/foo_r128scan), ...
C.R.Helmrich likes this. It's great to see how quickly developers people adopt R 128. Maybe there actually
is a real chance to end the loudness war.
Quick test with foobar 1.1.2 beta on two albums shows that the results are identical to those I got by hand from r128-sndfile.exe last week.
Minor beautification/question:
After scanning, the progress of which is nicely indicated in Win 7 on the taskbar icon , the icon still has a vertical green progress line, as shown below, even though scanning is finished.
(http://www.ecodis.de/audio/foo_r128gain.png)
During scanning, you show a semicolon-separated list of all files being processed, which is reduced one-by-one. Did you make sure that kind of handling is buffer-overflow-proof if one selects thousands of files at once? And wouldn't it be better to show just the currently processed file?
Thanks a lot for your work!
Chris
Updated again. I have not made any changes to the volume level adjustment for mono files. The algorithm processor itself should probably be adjusted instead. Or maybe the player's output components, or maybe the operating system itself. You know, since the DirectSound code uses WAVEFORMATEXTENSIBLE to output mono files to only the center channel, and it's up to the operating system, or the sound card's drivers, or whatever, to promote the result to the left and right speakers in a stereo setup.
And the progress indicator artifact was due to using a modal dialog from inside the threaded process callback instead of spawning a modeless dialog and returning.
While the status string should never overflow, since memory is allocated dynamically, I've changed it to only list the files currently being scanned. Of course, that will be up to four filenames at once on quad core or faster systems, since I limit the scanner to up to four threads.
Updated again.
Great work.
Id like to add just like "apply to data" as normalize.
Well.Ive using your foo_input_avs and reencode it for video file.
If this component will be stability then could you add it please
Yes I know its rectangle but those icons are 15x15(upper section is 22x22)
(http://img288.imagevenue.com/loc107/th_15105_8_122_107lo.jpg) (http://img288.imagevenue.com/img.php?image=15105_8_122_107lo.jpg)
foo_rgscan already has a function to apply the gain correction to MP3 files. Adding that to foo_r128scan would be redundant, not to mention I would have to code it from scratch, since the foo_rgscan code I have from 2004 did not have the mp3gain capability added yet.
foo_rgscan already has a function to apply the gain correction to MP3 files. Adding that to foo_r128scan would be redundant, not to mention I would have to code it from scratch, since the foo_rgscan code I have from 2004 did not have the mp3gain capability added yet.
Yes you are right?Of course?I understand it that only MP3(without e.g. vorbis read vorbis comment in ffdshow and mesepack ds filter)
I wish it is come true in the near future by this wonderful idea
You're free to keep foo_rgscan installed and use its mp3gain functionality.
Not sure if it's a bug, but:
When scanning as selection it seems to only use 1 core.
If I choose Scan per-file then it's using all my 4 cores.
Would also be good to see how fast it scans in the progress window not just in the results window, like the regular RG scanner.
Thanks.
Probably this issue is related to libebur128: http://www.hydrogenaudio.org/forums/index....st&p=740589 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86116&view=findpost&p=740589)
Select several (>=4) albums and choose "Scan as albums (by tags)". You'll see 100% CPU load.
Yes. Dividing a single album up onto multiple cores would require significant changes to the scanner library. I don't think foo_rgscan supports multi-threading single albums, either.
It does support.
Test with 15 tracks:
ReplayGain per-file: 400x (95%+ CPU).
ReplayGain albums by tags: 407xx (95%+ CPU).
R128 per-file: 481x (95%+ CPU).
R128 albums by tags: 133x (25% CPU).
Windows 7 Ultimate x64 SP1.
foobar2000 v1.1.2.
foo_rgscan 2.0.9.
foo_r128scan 1.12.
Are you sure the albums are being split by tags properly? One way to tell if it's scanning multiple threads at once is to observe how many file names are in the status window. It lists every file currently being scanned.
Oh, and foo_r128scan uses pfc::getOptimalWorkerThreadCountEx(), which calculates the number of threads to execute from the processor affinity mask. Have you set that to a single core, for some reason? Wait, blah, never mind, if that were the problem, your track scan task wouldn't be threading.
It's only one album, same tags for %album%.
Grouping pattern on both scanners: %album% | %date%.
Works fine with ReplayGain, and always has.
Thanks.
Woo,Thanks a lots for foo_r128norm
That makes me free as you say that
really smart head you have
I'm thinking of new functions for the library:
double ebur128_loudness_global_multiple(ebur128_state* sts, size_t size);
You could make one state for each track in parallel and get the result at the end.
int ebur128_change_parameters(ebur128_state* st, int channels, int samplerate);
To handle files with different channels / samplerates.
/* Set channel "channel_number" to value, where value is from the "channels"
* enum. */
int ebur128_set_channel(ebur128_state* st, int channel_number, int value);
To make channel setup easier.
Comments?
Parallelizing multiple tracks in a single album? Yes, that would be necessary to optimize album scanning for multiple threads. Of course, then it will also complicate my scanner.
Also, I currently handle sample rate changes by resampling, although I give up completely on channel count/type changes.
I've just applied R128 on my entire library and I must say it works way better than the original algorithm in ReplayGain, my harp and piano albums do not feel louder as before. The end result has a much better linearity of volume between all genres I listen to. Thank kode54 for bringing this to foobar2000, and thank anyone related in the creation of R128.
If you have an album with some tracks RG'd and some not, this scanner always says all tracks have RG values.
Not a huge thing as this only takes a mouse click, but it is incorrect.
How do you get some tracks tagged and some untagged?
Never edit tags while distracted...
Fixed to behave like foo_rgscan. Also, I implemented that function:
double ebur128_gated_loudness_global_multiple(ebur128_state** sts, size_t size);
It works perfect now.
Thank you!
I've uploaded version 0.1.9 of libebur128 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86116&st=50&p=741288&#entry741288).
I merged kode54's ebur128_loudness_global_multiple and adjusted it so that it can process states of different samplerates.
Can someone please inform me about the advantages of these new R128 methods/components?
I gave it a try and it seems to allow for gain processing in sections!?
For me it sounded a little bit unnatural/inbalanced as some elements were boosted alot while in quiet parts
and suddenly almost disappeared when the song became louder overall.
Are you sure you're using this component and not R128Norm which suppose to do what you described?
Updated. Due to how the scanner now handles sample rate and channel changes, results may differ from before. Also, when "true" peak scanning mode is enabled, the upsampled results are no longer fed through the R128 scanner, since it supports variable sample rates and sample rate changes on its own now.
Updated. Due to how the scanner now handles sample rate and channel changes, results may differ from before.
Which results?
I started with processing my files slowly, and just finished with first 1K from planned 10K files which I'll report here or on portal with RG to R128 comparison
So, am I early? Are any changes planned that may affect values in future that may make my log useless?
Thanks kode54
Well, any albums with mixed sample rates will differ from before, due to the previous version resampling, while this one simply reconfigures the scanner library.
Also, "true" peak mode will always differ, since before it would feed the upsampled audio through the scanner, while now it feeds it as-is, since it can reconfigure it if the audio format changes during the scan.
The difference is likely to be less than 0.5 dB, though.
Using 1.15, if I choose 3-4 albums and select Scan selection by album (using tags) foobar crashes somewhere around the 3rd album.
If I choose the same albums one by one and use the same scan, no crash.
I can confirm the same problem that GHammer is experiencing.
Sorry, I just updated to 1.16, could you try to reproduce those crashes again? I didn't think to scan the crash report database for different crashes from the one I just fixed before rolling out another release.
Also, this problem seems to only affect machines with four threads running at once. I'll have to fire up my laptop and see if I can reproduce it myself, although it's only dual core with HyperThreading, not a true quad core processor.
kode54, I want to thank you for this wonderful plugin. I do have a feature request at the risk of sounding like a heretic however. Would you consider adding a toggle, just like you do for "true" peak, that would allow switching to -23 - LUFS from -18 - LUFS if its not too much trouble? I would really appreciate it but would understand if the request is beyond the scope of your project.
Updated. I'll add a reference level configuration option to the next version, although I think it's kind of a pain to deal with something like that, since the way I tag files, there's no way to detect if I scanned them with a different level and force the new level.
Sorry, I just updated to 1.16, could you try to reproduce those crashes again? I didn't think to scan the crash report database for different crashes from the one I just fixed before rolling out another release.
Also, this problem seems to only affect machines with four threads running at once. I'll have to fire up my laptop and see if I can reproduce it myself, although it's only dual core with HyperThreading, not a true quad core processor.
Using 1.17, the crash is corrected on my machine. i5 CPU, Win 7 x64.
Yeah, a future version will support reporting which tracks failed to scan, so you can see where the errors are occurring.
Thanks for this component
I made some tests with it now and albums from one artist (or within a genre/style) are more balanced in loudness as with ReplayGain.
Newer albums with heavy dynamic compression doesn't sound louder anymore than older albums without dynamic compression.
Love it
But unfortunately albums from different genres/styles still differs from each other.
So Enya is "crying" her voice in my ears while AC/DC seem to whisper - compared with Enya, if you know what I mean...
So I still need to lower the "Enya results" at about 4dB manually to make them as "quiet" as the others, like I did with ReplayGain in the past.
So my question is:
Could it be possible to add two or three presets, where the user could select the preset an album should be scanned with?
I guess this is what spies suggested already as he asked for a switch to toggle between -23 and -18 LUFS.
To not annoy other users who don't need this "feature" an option in the advanced preferences could enable/disable the presets and only when it is enabled a window pops up where the user will be asked for "scan with preset 1/scan with preset 2..." before the album will be scanned.
I know it may be a sassy feature request and it isn't a really big effort for the user to fit the result manually after the scan if needed, but this is a feature I already missed while using ReplayGain...
Thanks
tedgo
Just move the RG preamp down to -5dB.
This would cause that all scanned albums are quieter. Not only the albums that are still too loud after the scanning process.
So Enya would still "sing" much louder than AC/DC
Imho it is better to have "replaygain_correction" or "replaygain_offset" tag for manual adjustment.
Updated, now with error reporting.
And a correction on that target level configuration. I won't be implementing that, simply because the file tags are supposed to target a specific loudness level. If you want the player to behave as if the scanner targeted a reference level of -23 LUFS, then set your tagged files preamp slider to -5 dB, like Canar posted.
I'm getting blank scan results after the last update. Also, last night when scanning using "scan selection as albums (by tags)" on multiple CD's from a box set foobar crashed
Kode54
Issue with this newest version. I tried with all three context scan methods. Scan runs and based on the time it takes seems to be working. However, scan results window is empty and nothing gets written to files.
EDIT: Context menu item - remove replaygain tags does work. No console hint of troubles.
Updated again, thanks.
Confirm issue gone and working fine for me.
thanks
I won't be implementing that, simply because the file tags are supposed to target a specific loudness level.
Thanks for considering it just the same. I suppose as long as it stays a known reference value, which is currently -18 LUFS, I can always manipulate the tags in the files afterward if I want a different reference value stored. Not as easy as having the option up front though
I did want to note that the main reason I was interested in this option is that I am not entirely convinced that -18 LUFS will be the final target in trying to match a ReplayGain target of 89 dB on my library. I was also interested in how the proposed -23 LUFS target value for EBU R 128 compares to ReplayGain's original proposed target of 83 dB on my library. In no way am I trying to suggest that these values should be different from what they are currently. In the end I will not be mixing values from the two scanners myself since I would rescan my entire library anyway so trying to match the values from one scanner with the other is not a concern to me.
I won't be implementing that, simply because the file tags are supposed to target a specific loudness level.
Thanks for considering it just the same. I suppose as long as it stays a known reference value, which is currently -18 LUFS, I can always manipulate the tags in the files afterward if I want a different reference value stored. Not as easy as having the option up front though
Today I encountered both r128gain (pbelkner) and foo_r128scan (kode54), in that order. r128gain adds two additional tags to track the reference values — at least, when using the program with its default settings — which seemed like a good idea, at least from my own limited perspective. For now I am adding similar tags to the files I've test-tagged, so that I remember (if need be) how foo_r128scan handles things:
REPLAYGAIN_ALGORITHM : EBU R128
REPLAYGAIN_REFERENCE_LOUDNESS : -18 LUFS
- M.
You can implement a quiet mode to apply automatically the gain, like the default scanner does?
Can also confirm both the empty scan results and foobar crashing are gone on the last update (1.20), thanks.
I did note, however, the scan result for an album I've been using to test each update are about 1 dB less than before. Can't remember it altering much, if at all, since the first version.
Here are some Album Gain data ReplayGain vs. EBU R128 True Peak.
(using foo_R128scan.dll Version 1.17, foobar2000 1.1.2)
(http://www.abload.de/img/pop4q7hi.jpg) (http://www.abload.de/image.php?img=pop4q7hi.jpg)
(http://www.abload.de/img/klassik4c7z2.jpg) (http://www.abload.de/image.php?img=klassik4c7z2.jpg)
Please note that the "true" peak method has no effect on the gain values anymore, as I don't pass the upsampled data through the scanner, I only use it for peak calculation. So, to speed up gain result comparisons, feel free to turn it off.
Funny, I thought the SDK already has SSE optimized functions for calculating the peak of audio_chunks o_o
Not for this upsampled bullcrap. Then I have to upsample the audio before running it through the optimized peak scanner.
Easy test which I'm sure some did before, but I just d/l papers and tests for potential reading:
| foobar2000 | R128GAIN | Difference
| gain peak | gain peak | gain peak
----------------------------------------------------------------------------------------------------
01. 1kHz Sine -20 LUFS-16bit | 1.95 0.100739 | -3.00 0.100733 | 4.95 0.000006
02. 1kHz Sine -26 LUFS-16bit | 7.95 0.050507 | 3.00 0.050508 | 4.95 -0.000001
03. 1kHz Sine -40 LUFS-16bit | 21.99 0.010254 | 17.00 0.010260 | 4.99 -0.000006
04. seq-3341-1-16bit | 4.95 0.071320 | 0.00 0.071316 | 4.95 0.000004
05. seq-3341-2-16bit | 14.96 0.023041 | 10.00 0.023049 | 4.96 -0.000008
06. seq-3341-3-16bit | 5.00 0.071472 | 0.00 0.071468 | 5.00 0.000004
07. seq-3341-4-16bit | 5.04 0.070801 | 0.00 0.070849 | 5.04 -0.000048
08. seq-3341-5-16bit | 4.95 0.100830 | -0.10 0.100845 | 5.05 -0.000015
09. seq-3341-6-5channels-16bit | 5.02 0.063080 | 0.00 0.063132 | 5.02 -0.000052
10. seq-3341-6-6channels-WAVEEX-16bit | 5.02 0.063080 | 0.70 0.063132 | 4.32 -0.000052
11. seq-3341-7_seq-3342-5-24bit | 4.98 0.358332 | 0.00 0.358340 | 4.98 -0.000008
12. seq-3341-8_seq-3342-6-24bit | 5.01 0.718294 | 0.00 0.718297 | 5.01 -0.000003
13. seq-3342-1-16bit | 4.59 0.100006 | -0.40 0.100088 | 4.99 -0.000082
14. seq-3342-2-16bit | -1.19 0.177826 | -6.20 0.177971 | 5.01 -0.000145
15. seq-3342-3-16bit | 2.01 0.100006 | -3.00 0.100088 | 5.01 -0.000082
16. seq-3342-4-16bit | 2.04 0.100006 | -3.00 0.100073 | 5.04 -0.000067
Track 10 problem is probably in it's format, but why this minor deviations? I know it's not important (can't be sensed), but curious what is causing +/- .05 difference - it's not like 6 digit error which can be overlooked. Or is it because of post #39 (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86404&view=findpost&p=741432)?
What are you comparing there? There are two scanners for foobar2000, and the R128GAIN tool writes values that don't compare to foobar2000 by default. If you want to compare R128GAIN's output with either foo_rgscan or foo_r128scan, set Algorithm to BS.1770 and Compatible to ReplayGain. Otherwise, you need to convert the LU offset results to approximate ReplayGain dB offsets by adding 5 to them.
Sorry if I posted wrong conclusion, but aren't "LUs" decibel units on same decibel referenced scale? I simply did not considered 5dB (no need for --rg-compatible switch), hence +/- 0.05.
I used this command line:
r128gain --r128 --true-peak=on *.wav -o c:\temp flac
than I posted tags in resulted FLACs and results made by your scanner
[edit] as said it's not big deal, only out of curiosity
Yeah, the results written by r128gain when using the pure --r128 mode will be in LU offsets, which are -23 - LUFS. My component applies -18 - LUFS, which is equivalent to running r128gain with the --rg-compatible switch.
It seems like source to this in not in foobar, but from libebur128-0.1.10-win32 (or perhaps in me?), although it's author posted different results in early stage: link (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86116&view=findpost&p=739176)
libebur128-0.1.10-win32for %x in (*.wav) do r128-sndfile.exe -r -t "%x"
global
loudness: LRA:
------------------------------------------------------------------------------------------------------------
1kHz Sine -20 LUFS-16bit.wav -19.95 LUFS 0.00 1.95382238 0.10073853 1.95382238 0.10073853
1kHz Sine -26 LUFS-16bit.wav -25.95 LUFS 0.00 7.95382395 0.05050659 7.95382395 0.05050659
1kHz Sine -40 LUFS-16bit.wav -39.99 LUFS 0.00 21.99266006 0.01025391 21.99266006 0.01025391
seq-3341-1-16bit.wav -22.95 LUFS 0.00 4.95355644 0.07131958 4.95355644 0.07131958
seq-3341-2-16bit.wav -32.96 LUFS 0.00 14.95986040 0.02304077 14.95986040 0.02304077
seq-3341-3-16bit.wav -23.00 LUFS 17.04 4.99589982 0.07147217 4.99589982 0.07147217
seq-3341-4-16bit.wav -23.04 LUFS 16.99 5.03591862 0.07080078 5.03591862 0.07080078
seq-3341-5-16bit.wav -22.95 LUFS 6.00 4.94999745 0.10083008 4.94999745 0.10083008
seq-3341-6-5channels-16bit.wav -23.02 LUFS 0.00 5.01715778 0.06307983 5.01715778 0.06307983
seq-3341-6-6channels-WAVEEX-16bit.wav -23.02 LUFS 0.00 5.01715778 0.06307983 5.01715778 0.06307983
seq-3341-7_seq-3342-5-24bit.wav -22.98 LUFS 5.07 4.98024250 0.35833156 4.98024250 0.35833156
seq-3341-8_seq-3342-6-24bit.wav -23.01 LUFS 2.24 5.00907772 0.71829414 5.00907772 0.71829414
seq-3342-1-16bit.wav -22.59 LUFS 10.00 4.58967232 0.10000610 4.58967232 0.10000610
seq-3342-2-16bit.wav -16.81 LUFS 5.00 -1.18933078 0.17782593 -1.18933078 0.17782593
seq-3342-3-16bit.wav -20.01 LUFS 20.00 2.01475665 0.10000610 2.01475665 0.10000610
seq-3342-4-16bit.wav -20.04 LUFS 15.00 2.03504371 0.10000610 2.03504371 0.10000610
r128gainr128gain --r128 --true-peak=on *.wav
SoX successfully loaded.
FFmpeg successfully loaded.
analyzing ...
1kHz Sine -20 LUFS-16bit.wav (1/16): -20.0 LUFS, -3.0 LU (peak: 0.100733: -10.0 dBFS)
1kHz Sine -26 LUFS-16bit.wav (2/16): -26.0 LUFS, 3.0 LU (peak: 0.050508: -13.0 dBFS)
1kHz Sine -40 LUFS-16bit.wav (3/16): -40.0 LUFS, 17.0 LU (peak: 0.010260: -19.9 dBFS)
seq-3341-1-16bit.wav (4/16): -23.0 LUFS, -0.0 LU (peak: 0.071316: -11.5 dBFS)
seq-3341-2-16bit.wav (5/16): -33.0 LUFS, 10.0 LU (peak: 0.023049: -16.4 dBFS)
seq-3341-3-16bit.wav (6/16): -23.0 LUFS, -0.0 LU (peak: 0.071468: -11.5 dBFS)
seq-3341-4-16bit.wav (7/16): -23.0 LUFS, 0.0 LU (peak: 0.070849: -11.5 dBFS)
seq-3341-5-16bit.wav (8/16): -22.9 LUFS, -0.1 LU (peak: 0.100845: -10.0 dBFS)
seq-3341-6-5channels-16bit.wav (9/16): -23.0 LUFS, 0.0 LU (peak: 0.063132: -12.0 dBFS)
seq-3341-6-6channels-WAVEEX-16bit.wav (10/16): -23.7 LUFS, 0.7 LU (peak: 0.063132: -12.0 dBFS)
seq-3341-7_seq-3342-5-24bit.wav (11/16): -23.0 LUFS, -0.0 LU (peak: 0.358340: -4.5 dBFS)
seq-3341-8_seq-3342-6-24bit.wav (12/16): -23.0 LUFS, 0.0 LU (peak: 0.718297: -1.4 dBFS)
seq-3342-1-16bit.wav (13/16): -22.6 LUFS, -0.4 LU (peak: 0.100088: -10.0 dBFS)
seq-3342-2-16bit.wav (14/16): -16.8 LUFS, -6.2 LU (peak: 0.177971: -7.5 dBFS)
seq-3342-3-16bit.wav (15/16): -20.0 LUFS, -3.0 LU (peak: 0.100088: -10.0 dBFS)
seq-3342-4-16bit.wav (16/16): -20.0 LUFS, -3.0 LU (peak: 0.100073: -10.0 dBFS)
You should mention that in the author's topic, in case he isn't following this one.
It seems like source to this in not in foobar, but from libebur128-0.1.10-win32 (or perhaps in me?), although it's author posted different results in early stage: link (http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=86116&view=findpost&p=739176)
Your results are perfectly fine. It's just that I rounded the values in that test to one significant digit.
edit: R128Gain rounds values to one significant digit before it writes them to the file, while foo_r128scan and r128-* use 2 significant digits.
Ah, yes, thanks for explanation. R128GAIN is presenting results with 1 digit precision and your lib with 2 digit precision
first table I posted has R128GAIN with 2 digit precision, which is not correct and reason is intermediate software I used before posting
+/- .05 should had ringed the bell, but it didn't
Here are some Album Gain data ReplayGain vs. EBU R128 True Peak.
By looking at the pics grimes posted above, it seems that r128scan is off by 1 dB (or LU) compared with ReplayGain over large numbers of albums.
What is the logic of choosing -18 LUFS? Wouldn't -17 LUFS be closer to the target as best compatibility with RG is desirable? Like the 6 dB shift from 83 to 89 SPL that was chosen for RG.
I've seen discussion about this here (http://www.hydrogenaudio.org/forums/index.php?showtopic=85978&st=200) and there (http://www.hydrogenaudio.org/forums/index.php?showtopic=85978&view=findpost&p=741864). Information and examples from both threads still lead me to think the current R128 scanner implementation is (about) 1 LU louder on average. If it's true, it would be better to adjust it sooner than later.
In the mentioned plot (http://www.hydrogenaudio.org/forums/index.php?showtopic=85978&view=findpost&p=741864), ReplayGain is 1LU louder than R128!
This is contrary to my results (R128 ~1LU louder than RG).
Here a similar plot R128 vs. ReplayGain of my classical productions already shown in post #62/2:
(http://www.abload.de/img/klassik8o7dm.jpg) (http://www.abload.de/image.php?img=klassik8o7dm.jpg)
In the mentioned plot (http://www.hydrogenaudio.org/forums/index.php?showtopic=85978&view=findpost&p=741864), ReplayGain is 1LU louder than R128!
This is contrary to my results (R128 ~1LU louder than RG).
I'm sorry I realize that using the term "louder" was not clear enough.
What I meant was when you would apply the calculated values as shown in your results in post #62 (http://www.hydrogenaudio.org/forums/index.php?showtopic=86404&view=findpost&p=741781), the result would be (on average roughly) 1dB louder with the R128scan values compared to the ReplayGain values.
It made me doubt that 5 dB/LU is the best offset.
edit: I decided to test a bit myself and for some "normal" jazz, pop and rock music the (album gain) result came close. For very bass heavy tracks it become all the more clear that ReplayGain ignores the low end too much, I'm not sure R128 ignores enough of it (maybe I just have to get used it's behaviour).
note to self: don't draw conclusions from 1 picture too quickly
Here are the plots of my bootlegs (note: these are no professional productions):
(http://www.abload.de/img/bootleg5hlc.jpg) (http://www.abload.de/image.php?img=bootleg5hlc.jpg)
(http://www.abload.de/img/bootlegtrackxes5.jpg) (http://www.abload.de/image.php?img=bootlegtrackxes5.jpg)
(http://www.abload.de/img/bootlegvsalbum3xf3l.jpg) (http://www.abload.de/image.php?img=bootlegvsalbum3xf3l.jpg)
(http://www.abload.de/img/bootlegvstrack3cem6.jpg) (http://www.abload.de/image.php?img=bootlegvstrack3cem6.jpg)
edit: R128Gain rounds values to one significant digit before it writes them to the file, while foo_r128scan and r128-* use 2 significant digits.
Just curious (not like it's a serious issue), but...
foobar2000 reports five significant digits for ReplayGain tags. How much overhead would be involved in calculating that level of precision with foo_r128scan, and how difficult would it be to implement a "high precision" mode to go along with the "true peak" mode, for testing?
— M.
foo_r128scan already logs in full double precision floating point values, but display and possibly tags are limited to two significant decimal places. I don't know where you are seeing these five significant digits of ReplayGain data, but the current version uses the same fixed two digits in the SDK when converting the floating point gain values to text for writing tags.
foobar2000 reports five significant digits...
Oops! I meant
six significant digits. Silly me, posting before coffee and all!
— M.
foo_r128scan already logs in full double precision floating point values, but display and possibly tags are limited to two significant decimal places. I don't know where you are seeing these five significant digits of ReplayGain data, but the current version uses the same fixed two digits in the SDK when converting the floating point gain values to text for writing tags.
I was looking at the values displayed by selecting "Edit ReplayGain Information" from within the ReplayGain context menu, with the assumption that if six decimal places are shown, there might be a reason. So foobar2000 calculates more precise values than it bothers to display, even though the display exists? Seems like an odd choice.
— M.
On ambient style albums I like the results much better than those of ReplayGain. Less too loud tracks.
I'm pleasantly surprised.
Just a few remarks on the cosmetics, I know, the least important part
- The order in the Scan results window is the order the scans were completed, not the order of the selection (as with RGscan). So long tracks often appear later.
- The position of the result window is not remembered
BTW The file names without the path, in the progress window, make more sense than those of RGscan.
I was just thinking we needed a new normalizing tool and found this Thanks for your work and I am glad I erased my ReplayGain tags months ago lol
I'm going to use this to get values for FLAC files then convert those into 160 aac vbr with neraacenc. Should I wait awhile or has everything been fixed?
I guess the number of significant digits depends on the tags used.
Updated.
I'm tempted to start using this but I'll wait a month till all the bugs are ironed out. Hell it was just updated yesterday lol
But that update only fixed a bug with odd sample rates, if you'll observe the change log. Everything should be pretty stable now.
Alright, I'm doing my entire FLAC library now, then afterward I'll use foobar2000 to convert into NeroAACEnc 190 VBR with gain applied. Thanks for this plugin I'm on Ubuntu and don't have any good audio programs that work except foobar2000. I use that for editing not playback, thanks!
I'd like to generate a text report for selected playlist entries, using a reference of -23dB LUFS.
How can I achieve this ?
Any pointers to where I can read up and gather information myself is appreciated. I don't want to burden anyone with having to explain basics to me, and am willing to do the leg work myself. I just need to know where to get started.
Ok, I'm going to apologize ahead of time for my ignorance, but everything you guys are talking about is going way over my head.
I understand the concept of the plugin... it's a volume normalizer, like ReplayGain. I just have a few questions if someone would be nice enough to answer some "stupid" questions for me.
1) What is the fundamental difference between this plugin and the standard ReplayGain routines/plugin that I have been using forever? In dumbed down terms, please.
2) If not already explained, is this plugin, based on that R128 method deemed "better" than RG or just an alternative. I saw mention of how it resampled to 192khz, or rather would like to...
3) Does this physically normalize the waveforms, or does it write tags like RG that are read and used to adjust peaks? read that it uses standard RG tags
4) This is probably unrelated, but it kept coming up in this thread, so I will go ahead and ask: I understand what sampling rate is, and from what I know, the two main choices (for converting between two) are the SoX and PPHS DSP's. Is either one of these "superior" or "preferred" over the other, or are they just different versions of the same thing, really? I have always wondered which to use when needed. I can research some more on that topic in other threads, but if anyone has a quick answer, that'd be great.
From what I could gather from reading the posts, this is essentially an alternative to ReplayGain, which is able to more accurately find the true peaks in tracks, or at least "more accurately" determine them? If you have already RG'ed your tracks, is there a strong reason to rescan using this plugin? I don't use like super high end equipment or anything, so...
Anyway. Thanks, and I hope I haven't bothered anyone by asking those questions... I'd just like to be more educated on this topic, as this R128 algorithm or method of scanning audio files is something brand new to me.
There have been a couple of fixes for libebur128. Will there be an update for this plugin?
i suspect most will likely choose to simply upgrade to foobar2000 v1.1.6 beta (http://www.hydrogenaudio.org/forums/index.php?showtopic=87559) which now has native support for libebur128.
Yes, when 1.1.6 goes final, this component will be discontinued.
Yea I just scanned my stuff with the new foobar2000 replaygain implementation, it's .01 variance from your plugin :/ I'm not gonna waste time re-scanning and trans-coding my FLAC's again it's not that much of a difference, but :/
it's .01 variance from your plugin
That might be a matter of rounding/truncating, the integrated RG scanner writes 2 decimals, like it always did. This plugin wrote 6 decimals. I can assure you, the difference is neglectable.
Edit: what I said seems to be the case for mp3, replaygain values in FLAC files are displayed with 6 decimals. I am very sorry for the confusion.
interesting
R128Gain was updated with EBU R128-2, will you be updating your utility to work with it?
re-read post #93 on this page...
Not to mention that this utility and foobar2000 itself use libebur128, not R128Gain, so any changes to R128Gain would have to be ported over to the other library.