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.
Topic: libebur128 - (yet another) EBU R 128 implementation (Read 155942 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

libebur128 - (yet another) EBU R 128 implementation

Reply #125
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

libebur128 - (yet another) EBU R 128 implementation

Reply #126
::

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


Greetings ...

::

libebur128 - (yet another) EBU R 128 implementation

Reply #127
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?


libebur128 - (yet another) EBU R 128 implementation

Reply #129
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.

libebur128 - (yet another) EBU R 128 implementation

Reply #130
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.

 

libebur128 - (yet another) EBU R 128 implementation

Reply #131
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

libebur128 - (yet another) EBU R 128 implementation

Reply #132
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.

libebur128 - (yet another) EBU R 128 implementation

Reply #133
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.

libebur128 - (yet another) EBU R 128 implementation

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

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

Greetings ...

::

libebur128 - (yet another) EBU R 128 implementation

Reply #135
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

libebur128 - (yet another) EBU R 128 implementation

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

libebur128 - (yet another) EBU R 128 implementation

Reply #137
[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

libebur128 - (yet another) EBU R 128 implementation

Reply #138
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

libebur128 - (yet another) EBU R 128 implementation

Reply #139
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.

libebur128 - (yet another) EBU R 128 implementation

Reply #140
Quote
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: [Select]
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


libebur128 - (yet another) EBU R 128 implementation

Reply #141
Code: [Select]
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: [Select]
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:

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

libebur128 - (yet another) EBU R 128 implementation

Reply #142
Quote
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!

libebur128 - (yet another) EBU R 128 implementation

Reply #143
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: [Select]
emerge -u layman
layman -a pro-audio
emerge -av r128-scanner

libebur128 - (yet another) EBU R 128 implementation

Reply #144
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!

libebur128 - (yet another) EBU R 128 implementation

Reply #145
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

libebur128 - (yet another) EBU R 128 implementation

Reply #146
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.

libebur128 - (yet another) EBU R 128 implementation

Reply #147
::

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


Greetings ...

::

libebur128 - (yet another) EBU R 128 implementation

Reply #148
... 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.

libebur128 - (yet another) EBU R 128 implementation

Reply #149
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.

Quote
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