10 Dec
2011
10 Dec
'11
11:38 a.m.
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