libebur128 - (yet another) EBU R 128 implementation Options

[Raiden]

I've uploaded 0.3.2 that fixes the slow down issue with denormal numbers. I'm using the "Fix-up solution" from here.

Download

[Surfi]

::

Thanks! (... but can't download, receiving zero-byte achives.)
Any chance for getting a true peak tagging option?


Greetings ...

::

[Raiden]

Thanks! (... but can't download, receiving zero-byte achives.)

Whoops, went over my quota... the archives should be uploaded now.

Any chance for getting a true peak tagging option?

I'm not sure about this. I really want to follow the ReplayGain spec, but maybe adding a hidden, undocumented option for those you really want this feature won't hurt.


I've got a question about BS.1770: How is 7.1 audio handled?

[Surfi]

..., but maybe adding a hidden, undocumented option for those you really want this feature won't hurt.

Awesome!

I've got a question about BS.1770: How is 7.1 audio handled?

I'm sorry to say that I've no idea.

[gjgriffith]

Thanks again for such a great tool.

I've noticed that mono flacs are tagged for 3.01 dB more gain than a stereo (dual-mono) equivalent. ReplayGain does not work this way (it will calulate identical gain).

Although I understand why it is doing this (one speaker is 3 dB quieter than two), the vast majority of players will treat a mono file identically to its dual-mono equivalent, thus the present tagging will result in the mono flac playing 3 dB louder than its dual mono equivlaent.

Is there a chance of either changing this or adding an option to change it? I don't have many mono flacs, but I have enough that I don't relish tracking them down and treating them differently than stereo flacs.

[Raiden]

Is there a chance of either changing this or adding an option to change it?

I agree. Mono files should be treated as dual mono for the RG tags. Fixing this now.

[Emery]

I've been using this to set gain levels in an FM station's automation system and it tears through files four times faster than the last analyzer I was using.
Thanks

This post has been edited by Emery: Apr 9 2011, 04:30

[audionuma]

ITU-R BS.1770-2 available.
75% overlapping and -10 dB relative gate ...
I guess the R128 should soon be modified in the same way.

[Raiden]

ITU-R BS.1770-2 available.
75% overlapping and -10 dB relative gate ...
I guess the R128 should soon be modified in the same way.

Great! Time to change the relative gate accordingly. The block overlap already is at 75%.

I've been using this to set gain levels in an FM station's automation system and it tears through files four times faster than the last analyzer I was using.

Thanks for the positive feedback

I should be releasing 0.4 in the next few days. Now there is only one scanner executable with different input plugins instead of one exe for each input library. The scanner automatically chooses the best input plugin for each file. This should make it easier to tag/scan different audio formats at the same time.
I've also implemented a hidden option "--tag-tp" for true peak tagging and fixed the ReplayGain loudness for mono files.

[Surfi]

I've also implemented a hidden option "--tag-tp" for true peak tagging ...

::

Thank you very much!
Can't wait to try it.

Greetings ...

::

[Raiden]

Finally, 0.4.0 is up! Now on GitHub, too!

change log:
- reorganized the project folder structure. The scanner and the library each get their own subdirectory.

Scanner:
- there is only one scanner executable now, using input plugins. The scanner will automatically choose the best plugin for each file. To get the old behaviour, use the option "--force-plugin" with a plugin name.
- add hidden --tag-tp flag for true peak ReplayGain tagging.
- improved output and help screen
- fix ReplayGain scanning for mono files

Library:
- set relative gate to -10dB according to the new BS.1770 revision
- don't expose library internals in header
- add dual mono support (a mono channel that counts twice, needed for proper ReplayGain support)


Download

[krafty]

Thanks Raiden! Looking forward to re-scan my entire library when fb2K incorporates this version.

[habasud]

[quote name='Raiden' date='Apr 26 2011, 00:24' post='753399']
Finally, 0.4.0 is up!

I noticed that files ending on ".MP3" are not processed properly. When I change the ending to lowercase everything works as expected...

Claus

[habasud]

I've tinkered a little bit and found out, that the ffmpeg plugin is loaded when I use "force-plugin=ffmpeg0.5.2". Then files with the "MP3" ending in capitals are analysed. Just "...=ffmpeg" didn't work. Unfortunately some of the filetypes supported by ffmpeg don't work anymore. E.g. "mov" video files aren't recognized.

When a plugin can't be loaded the scanner nevertheless exits with exit code "0". Maybe it would be a good idea to change this.

So I think that the "case sensitivity" is not the point. Maybe different plugins are loaded depending on the ending - I don't know. Perhaps a debug option like "-v" that prints out the used plugin could help to determin, which plugin causes which behavior.

I used the precompiled 32bit/sse2 version on ubuntu...

Hope this helps - thanks!
Claus

[Raiden]

I've tinkered a little bit and found out, that the ffmpeg plugin is loaded when I use "force-plugin=ffmpeg0.5.2". Then files with the "MP3" ending in capitals are analysed. Just "...=ffmpeg" didn't work. Unfortunately some of the filetypes supported by ffmpeg don't work anymore. E.g. "mov" video files aren't recognized.

Thanks for your feedback, the file extension recognition is now case insensitive.
When forcing the plugin, is the mov file analyzed? I've hardcoded the most common extensions in the input_*.c source files but forgot mov.

When a plugin can't be loaded the scanner nevertheless exits with exit code "0". Maybe it would be a good idea to change this.

So I think that the "case sensitivity" is not the point. Maybe different plugins are loaded depending on the ending - I don't know. Perhaps a debug option like "-v" that prints out the used plugin could help to determin, which plugin causes which behavior.

Sounds good, I'll implement this.

[habasud]

When forcing the plugin, is the mov file analyzed? I've hardcoded the most common extensions in the input_*.c source files but forgot mov.

No, it isn't:

CODE

user@lappi:~$ r128-scanner --force-plugin=ffmpeg0.5.2  Desktop/cimg9753.mov  
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x9fc7b20]moov atom not found
Could not open input file!
nan LUFS, Desktop/cimg9753.mov
--------------------------------------------------------------------------------
-inf LUFS

[pbelkner]

CODE

user@lappi:~$ r128-scanner --force-plugin=ffmpeg0.5.2  Desktop/cimg9753.mov  
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x9fc7b20]moov atom not found
Could not open input file!
nan LUFS, Desktop/cimg9753.mov
--------------------------------------------------------------------------------
-inf LUFS

This message seem to com from FFmpeg. The same message should appear if you run

CODE

ffmpeg -i Desktop/cimg9753.mov

There's a tool called "qt-faststart" which may help to re-arrange the MOV in order that FFmpeg can deal with it:

This utility rearranges a Quicktime file such that the moov atom is in front of the data, thus facilitating network streaming.

This post has been edited by pbelkner: Apr 29 2011, 06:57

[habasud]

There's a tool called "qt-faststart" which may help to re-arrange the MOV in order that FFmpeg can deal with it

:

Yes, it worked - Thank you! I tried to analyse the mov with the old r128-ffmpeg and I must admit that it didn't handle the file either... sory!

[Emery]

I liked this so much I packaged it for gentoo and put it in the proaudio overlay.
So if you're using gentoo, you can install by doing this,

CODE

emerge -u layman
layman -a pro-audio
emerge -av r128-scanner

[Raiden]

I liked this so much I packaged it for gentoo and put it in the proaudio overlay.

Wow, this is pretty awesome. Thanks for your efforts!

This post has been edited by Raiden: May 12 2011, 00:25

[R_R]

Hello Raiden,

First, many thanks for your work on this.

I'm using the gentoo packet from the pro-audio overlay (tx Emery!). I've already scanned my collection, with very good results, but there are some glitches I want to share.

flac and ogg files get overwritten perfectly. No problem there.

On mp3 files, tags are not overwritten but duplicated.

On mp2 files there is an error when using the default plugin:
This error doesn't happen when forcing the ffmpeg plugin, but in any case tags are not written, contrary to stdout indication. This is a sample command output with default plugin:

> r128-scanner -t track Radio/+La_Casa_del_Sonido-110527.mp2

[id3.c:940] error: Invalid UTF16 surrogate pair at 982 (0xfeff).
[id3.c:940] error: Invalid UTF16 surrogate pair at 982 (0xfeff).
0.06 dB, sample peak: 0.53888178, Radio/+La_Casa_del_Sonido-110527.mp2
--------------------------------------------------------------------------------
0.06 dB, sample peak: 0.53888178
tagging...

I usually tag .mp2 files with Ex falso. They are ES mpeg files recorded from DVB card.

Thanks in advance,

Roberto

[Raiden]

On mp3 files, tags are not overwritten but duplicated.

I can't reproduce this. Are your files tagged with ID3v1 tags? The scanner will always write ID3v2 tags which could show up as duplicates.

[id3.c:940] error: Invalid UTF16 surrogate pair at 982 (0xfeff).
[id3.c:940] error: Invalid UTF16 surrogate pair at 982 (0xfeff).

I can't really supress those errors from the mpg123 library. It looks like your input file is somehow corrupt. I wouldn't worry about it, though.

but in any case tags are not written, contrary to stdout indication.

Support for mp2 tagging is now in newest git. I'll try to get a new version out soon.

[Surfi]

::

... don't forget to correct the issue noted in post #138, please. Mixed case endings should also be processed properly.


Greetings ...

::

This post has been edited by Surfi: Jul 20 2011, 06:46

[Raiden]

... don't forget to correct the issue noted in post #138, please. Mixed case endings should also be processed properly.

This should be fixed in newest git.

[R_R]

On mp3 files, tags are not overwritten but duplicated.

I can't reproduce this. Are your files tagged with ID3v1 tags? The scanner will always write ID3v2 tags which could show up as duplicates.

Yes, this seems to be the case, thank you.

Support for mp2 tagging is now in newest git. I'll try to get a new version out soon.

Great, this will be a very appreciated adition for me. Thanks again,

Roberto