You really should do that. After all that's the only thing that counts. Currently I'm in the process to convert my whole audio collection in order to get an impression. The first results are very promising.

Wow, thank you so much for this tool! I was already mentally preparing myself to have to write my own R128 scanner, but here it is! And in version 0.2, it already does all I need.

Having said that...

When I pass a file path with spaces and without "enclosing quotes", or a file which doesn't exist, it prints an assert and crashes.

Other than that, it seems to analyze as expected, but I have some questions after looking at the source code.

For the loudness analysis, all input files are resampled to 48 kHz, right?

For the peak finder, the files are additionally resampled to 192 kHz, right?

The way I understand R128 is:Pass 1: analyze entire file/album, compute loudness taking into account the absolute gate of -70 LUFS.Pass 2: analyze entire file/album again, this time also taking into account the relative loudness gate derived from the result of pass 1. Is that how you implemented it?

These filter coefficients are for a sampling rate of 48 kHz. Implementations at other sampling rates will require different coefficient values, which should be chosen to provide the same frequency response that the specified filter provides at 48 kHz. The values of these coefficients may need to be quantized due to the internal precision of the available hardware. Tests have shown that the performance of the algorithm is not sensitive to small variations in these coefficients.

It is not obvious for me how to quantize the given coefficients with respect to other sample frequencies, hence I decided to re-sample to 48 kHz

The current version of R128GAIN combines all this in order to avoid multiple passes:

Attenuate by 0.5 (i.e. ca. 6 dB, future versions will correct this).

Up-sample to 192 kHz (i.e. approximately 4 x over-sampling)

Determine "true" peak.

Down-sample to 48 kHz in order to match defined filter coefficients.

Apply R128 algorithm.

QUOTE (C.R.Helmrich @ Jan 6 2011, 00:23)

The way I understand R128 is:Pass 1: analyze entire file/album, compute loudness taking into account the absolute gate of -70 LUFS.Pass 2: analyze entire file/album again, this time also taking into account the relative loudness gate derived from the result of pass 1. Is that how you implemented it?

On a completely other note... What about patents? Is it safe to use your tool in other projects?

No. Its not safe for non "open source" projects.

The only way for major closed source players like FB2K to use it would involve complete, clean room reimplementations. Which means you run into the same issues as ReplayGain with differing implementations.

Note that "use" in mudlord's post is about reusing code from it, not launching it as a standalone tool.

If you ever split out the guts of the tool into a backend library, please consider relicensing it under a non-copyleft license like MIT or zlib, so it can be used in other software like a foobar2000 component.

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

The only way for major closed source players like FB2K to use it would involve complete, clean room reimplementations. Which means you run into the same issues as ReplayGain with differing implementations.

Huh, it is a stand alone program and not a library that you link to. As long as the closed sourced players invokes it as an external helper program, there is no problem. The closed source players can even distribute it as long as the license is intact and the source code, or a link to the source, is provided.

The only way for major closed source players like FB2K to use it would involve complete, clean room reimplementations. Which means you run into the same issues as ReplayGain with differing implementations.

Huh, it is a stand alone program and not a library that you link to. As long as the closed sourced players invokes it as an external helper program, there is no problem. The closed source players can even distribute it as long as the license is intact and the source code, or a link to the source, is provided.

I'd rather a implementation of it in the host audio player rather than a outside application.

Even if the end artifact is a program, this prevents anyone from lifting source code from it (with proper attribution), or preventing anyone from forking it into a library with a sane license. So the license matters, even for a standalone application.

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

If you ever split out the guts of the tool into a backend library, please consider relicensing it under a non-copyleft license like MIT or zlib, so it can be used in other software like a foobar2000 component.

Yes, and let other people leech off your work without contributing back.

If you ever split out the guts of the tool into a backend library, please consider relicensing it under a non-copyleft license like MIT or zlib, so it can be used in other software like a foobar2000 component.

Yes, and let other people leech off your work without contributing back.

Eh? Using non-copyleft licenses and being a douche are orthogonal concepts. If you want to steal code, you can just ignore licenses like Miriam and steal anything you want.What I'm saying is that the choice of license (uninformed or informed) prevents use of part of the software in other software.If more kinds of applications can use the code, the quality of the code improves. More software exercising the code in different ways makes it more robust. An interface that only has one client tends to be very brittle and idiosyncratic.

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

If more kinds of applications can use the code, the quality of the code improves. More software exercising the code in different ways makes it more robust. An interface that only has one client tends to be very brittle and idiosyncratic.

Huh, how can the quality of the code improve since the changes in the closed source program is by definition "closed"? No one outside can see them.

If a developer uses a library with one of the usual non-copyleft open source licenses, he's bound by the license to make any alterations to the library available.As such, if the library needs alterations to work in the software (may it be open source or not), the changes the developer makes will be made available (and probably contributed back in the form of patches) to the original author.If the library works perfectly fine, all is good, both for the original author and for the developer.

--------------------

Zao shang yong zao nong zao rang zao ren zao.To, early in the morning, use a chisel to build a bathtub makes impatient people hot-tempered.

If a developer uses a library with one of the usual non-copyleft open source licenses, he's bound by the license to make any alterations to the library available.

Really, how about BSD or MIT?

Back on topic. For a library, I will actually choose LGPL. This allows any program (open or closed) to be linked against it. However, if the library is modified (and distributed), the changed source code must be made available.