Excerpts from Adrian Knoth's message of 2011-12-10 11:38:03 +0100:
Anyway, thanks for helping :)
> Maybe you need to motivate your wish for "replaygain for audio tracks in
most videos these days aren't real movies but amateur productions
off youtube or whatnot. Admittedly most people watch those
in-browser using flash. Either way, I would argue that
professionally produced movies are a minority these days.
> I'm only quoting Bob Katz on this, I've never mastered a Hollywood
If normalization would be sufficient, there wouldn't have been a
need for replaygain in the first place. Explanation on
Right, this should do. Is there an API for that? Either way, I think the
calculation could be done on the dumped audio and the dumped audio file
could be deleted immediately afterwards, provided it's possibly to add
tags without re-encoding or re-muxing.
> > After that, the scanning process should work as with any audio file.
Ah, I didn't think of adding metadata to the audio itself, another
possibility. However, adding it to the container would probably be more
> > Playback Video players need to be aware of those tags, read the
Yes, this is the major issue, an uphill battle. Replaygain fights it
since ten years. I realize that the result of the project would not be a
practical solution but rather a proof of concept or a first step.
> That is why normalizing in the player's output chain (see (2) above) or
Alex Stone, I guess :)
I discussed connection management with him a long while ago, the idea to
write something that can handle hundreds of ports well stems from there.
> > - A simple but hopefully sane mplayer GUI
I mostly use smplayer, but I'm not exactly happy with it although it's
pretty much the official frontend at the moment.
Here's an audio related bug report I filed more than a year ago that got
Even more annoying is that the volume suddenly increases after a while,
apparently once a certain threshold is reached.
I want to write something that doesn't have bugs like those and that has
sane file and playlist management.
> In any case:
Many of those are dead links and even the reasonably popular frontends
are rather bad (gnome-mplayer, which doesn't depend on gnome and has
lots of really stupid interface decisions that make it unusable).
But yes, chances are I'd just add another dead link.
> > Another problem I might have is that most students in the course are
That's a rather good idea, thanks.
If you have a good idea, please tell me. I'll have to find a team on
monday and it might help to have some good proposals.
Linux-audio-dev mailing list