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.

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%.

QUOTE (Emery @ Apr 9 2011, 03:44)

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.

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)

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'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.

QUOTE (habasud @ Apr 28 2011, 12:57)

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'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: