Re: [LAD] Replaygain for video?

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hoi Philipp, On 12/09/2011 09:20 PM, Philipp wrote: #ffmpeg -i YOUR_VIDEO_FILE -vn -acodec pcm_f32le -f wav /tmp/file.wav #sndfile-info /tmp/file.wav # prints max gain. Actually, you just need to decode the audio-track, not extract it; Alas sndfile-info only calculates the peak-value for seekable audio files not pipes. https://github.com/avuserow/ffmpeg-replaygain seems to do what you want but requires ffmpeg av* libs <=0.5 and/or a bit of patching. Theoretically easy. Practically it depends on the video-codec, container-format and library support to re-write the meta-data in-place. Worst case: you'll have to create a new file, copy the codecs, but rewrite the container. Note that you may need to calculate and store the gain for _each_ audio-track. Many films include two or more tracks: e.g. stereo and 5.1. # ffmpeg-options -ac <channel-count> -map <audio-track> I don't know any command-line apps to modify meta-data on a per track basis in-place (maybe ffmpeg can do that?), but the new liav* meta-data API is pretty nifty. Spot on. Have you checked #replaygain-video on irc.freenode.net ? Might be dead by now.. http://forum.xbmc.org/showthread.php?t=39320 Yes. the big knob on your PA labeled "Volume" :) I don't think it'll be particularly useful to have replay gain for movies. A compressor plugin (for video-players that don't yet have one) would be much more useful in the real world because - purists won't care for neither replaygain nor compression - consumers will complain that replay-gain is not sufficient for long[er] films and won't care about sound-degradation by compression gstreamer has all the building blocks (audio-gain, meta-data parser); for a quick/dirty prototype. But adding a gain-factor is trivial in every player [that has already mete-data parsing]. The most difficult will be to find an entry-point and the place where to add the gain scaling code. esp. in larger projects like mplayer, VLC or totem. Unless you want this to remain a school project, check for "easiest player to get it included upstream"; that'll indirectly make it easy to hack :) rather inexperienced -> /build one to throw [it] away/. Re-build it with then experienced students :) On a scale from 1(trivial) to 10 (very hard). I'd place it on 6. One one side there's a lot of code that can be re-used (libreplaygain, ffmpeg,..) yet their documentation is very compact for experts. On the other side it requires diligence and some maths knowledge. Integration in desktop-enviroments also needs some digging (e.g. hooks on mime-types for file-manager integration, trigger re-scan on demand, in the background,..) It's a great educational project with many problems that one will encounter in other /real-world/ projects. For an experienced coder the analyzer, meta-data re-write, mplayer gain filter code would be less than a day of work. Documentation, [social] interaction with upstream, maintenance, etc can easily take over a year. Did you try http://www.akjmusic.com/software/jackctl20110317.py ??! RFTL. http://www.mplayerosx.ch/ :( You can x-compile for windows and test with wine. ffmpeg is x-platform, as is mplayer and gstreamer. ..just be prepared to throw in a day or two to set up a x-platform build-environment.