I'm thinking about a component similar to the ReplayGain scanner but scanning DR values (more information) instead. I wonder if there is an easy/quick way to mirror the features of the ReplayGain scanner like context menu entries, dialogues, file reading/decoding and tagging. If not it seems to be a rather complex task (for me at least). I already have the calculation algorithm built into a standalone console application but would like to use foobar2000 for decoding of various formats (currently I use FMOD) and tagging. In the case that someone who is more experienced with the SDK would like to do the job I'd be happy to share my code.

I think you will already be able to calculate this with the current RG-scanned values. You have a floating point value for the "roof" (peak) and the reference point (gain). The distance between these should be pretty much the same. However, calculating floating point values with titleformatting may be tricky.

The DR values are calculated using a specific formula and cannot simply be derived from the RG values. I want official DR values, not just something similar.

This is something that I too would find useful. The DR-meter is designed to measure dynamic compression while RG is for lowering tracks to the same perceived volume.

IIRC the DR value is just the difference of the peak value from the RMS value over some window, like the length of a track. There have been discussions about this before on Hydrogenaudio, but it's not a particularly good estimator, if I recall correctly.

Edit: More info here: http://www.hydrogenaudio.org/forums/index....showtopic=68945

I know the formula. I already wrote a command line application implementing the exact specification (an active member can download it from the PMF site as PDF). That's not the problem. The problem is writing a foobar2000 component that does the scanning and tagging. The ideal solution would be a replica of the ReplayGain scanner but with different values and tags.

For my waveform seekbar, I wrote my own processing backend service to do the scanning and storage. As there's no central API for feeding a set of files through some processing functionality with UI feedback, rolling your own is probably your best bet.
If I had some of that mythical »free time«, I'd make this more generic, but as it stands now, it's highly specific to my components.