Re: [LAD] Replaygain for video?

On 12/09/11 21:20, Philipp wrote:

Hi!

> Well, I need a programming project for a university course and this is
> just one of my ideas that I want to propose to my teacher and
> prospective teammates. In order to do this I'd like to narrow it down a
> bit further and especially want to find out whether I have the right
> idea of how it can be achieved.

Let me start with discouraging you. ;) Don't do it.

Maybe you need to motivate your wish for "replaygain for audio tracks in
video files" a bit more, but basically, I see two points against it:

   1. Real movies always have the right audio level, there's a universal
      standard in the industry that's obeyed by mastering engineers. In
      other words, replaygain is not needed here.

      I'm only quoting Bob Katz on this, I've never mastered a Hollywood
      production. ;)

   2. Players like VLC have a normalize function. I don't know if it's
      one-pass (on the fly, more like automated gain control) or two-pass,
      but it basically solves your problem of audio levels at playback
      time.

Given that (2) is universal wrt input formats, I see little to no
additional value in your proposed project.

> Scanning/tagging Since replaygain works on whole audio files I think I
> need to extract the whole audio track from the container.

Demuxing, yes.

> How easily this can be achieved I don't know.

There are special tools. If nothing helps, vlc and mplayer can do this.
mplayer with -dumpvideo and -dumpaudio, vlc with the transcode commands.

> After that, the scanning process should work as with any audio file.
> Afterwards the calculated replaygain values have to be added to the
> metadata of the file.

Provided that the audio track supports meta data. Depending on the
container, you can embed almost everything from pcm to ogg, mp3, mp4/aac
and so on.

Depending on the container, it might be possible to add the meta data to
the muxed file.

> Playback Video players need to be aware of those tags, read the
> metadata and scale the playback volume accordingly. This is probably

See, this is where your problem starts. Too many formats, too many
players. This alone should be reason enough to move on and do something
useful instead.

That is why normalizing in the player's output chain (see (2) above) or
starting with decent levels (1) is the right approach.

> Other ideas I have are in short: - A CLI (using readline) connection
> manager for jack audio/midi and alsa midi that can handle large
> numbers of ports. More detailed ideas exist thanks to Julien Claasen.

Hmm, IIRC, we have at least one oomidi user (sorry, forgot the name, a
guy from Russia) who's making heavy use of this.

> - A simple but hopefully sane mplayer GUI

smplayer? I don't know if mplayer already supports DVD menus. That's
something you could work on.

In any case:

   http://www.mplayerhq.hu/design7/projects.html

Scroll down to "frontends".

> Another problem I might have is that most students in the course are
> Windows users, not sure whether I can go solo.

Create them an image to be used with virtualbox. ;)

Cheers

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Dec 10 12:15:02 2011