Hi,
It would be nice if Pytone could support this. It seems pretty simple, music files are tagged with the necessary information to allow music players to adjust volume during playback.
I got the information from:
http://sjeng.org/vorbisgain.html and http://replaygain.org/
I frequently have to adjust my set when using pytone and this seems to be a simple but effective solution.
I found no any information in the TODO about future support for something like this, so I thought I'd mention it :)
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Hi,
On 12.07.05, Dag Wieers wrote:
It would be nice if Pytone could support this. It seems pretty simple, music files are tagged with the necessary information to allow music players to adjust volume during playback.
I got the information from:
Sometime ago, I had a look at ReplayGain - to find that it has been proposed almost four years ago, and that since then the proposal has not been updated. In particular, I didn't find any description of the ID3 tags used by this standard. In the case of VorbisGain, the situation seems to be better. Still, I do not yet fully understand the meaning of the track and album gain thing. Which one should be applied when?
Maybe somebody has more information about this.
Jörg
* Joerg Lehmann joerg@luga.de [2005-07-17 16:40]:
Sometime ago, I had a look at ReplayGain - to find that it has been proposed almost four years ago, and that since then the proposal has not been updated. In particular, I didn't find any description of the ID3 tags used by this standard. In the case of VorbisGain, the situation seems to be better. Still, I do not yet fully understand the meaning of the track and album gain thing. Which one should be applied when?
Maybe somebody has more information about this.
Jörg
Hi Jörg,
didn't you find anything in the HydrogenAudio Forums (http://www.hydrogenaudio.org/forums/)?
A little search on replaygain gave me a tremendous amount of hits :)
HTH Stefan
############################################################# # My very personal wishlist for Pytone - just ignore it ;-) # ############################################################# * BPS recognition Show the bits per seconds from a song in the MP3 info window
* Indicate time when playlist will stop Show not only the entire time a playlist will last but as well the daytime it will end :)
* Modifiable playlists Modify/delete playlists
* Pause between tracks
* Some sort of replaygain -- Stefan Wimmer swimmer@xs4all.nl
Hi Stefan,
On 17.07.05, Stefan Wimmer wrote:
didn't you find anything in the HydrogenAudio Forums (http://www.hydrogenaudio.org/forums/)?
I found a link to that forum, however, didn't look around too much. Is it really necessary to search in an internet forum to get information about this "standard"? Oh well...
A little search on replaygain gave me a tremendous amount of hits :)
Yes, too many ;-)
I even don't know how to add ReplayGain tags to an mp3 file. There is mp3gain, which adds some tags but also changes the file itself. But this is obviously not what one wants - otherwise nobody would complain that PyTone doesn't support ReplayGain...
Jörg
On Sun, 17 Jul 2005, Joerg Lehmann wrote:
On 17.07.05, Stefan Wimmer wrote:
didn't you find anything in the HydrogenAudio Forums (http://www.hydrogenaudio.org/forums/)?
I found a link to that forum, however, didn't look around too much. Is it really necessary to search in an internet forum to get information about this "standard"? Oh well...
A little search on replaygain gave me a tremendous amount of hits :)
Yes, too many ;-)
I even don't know how to add ReplayGain tags to an mp3 file. There is mp3gain, which adds some tags but also changes the file itself. But this is obviously not what one wants - otherwise nobody would complain that PyTone doesn't support ReplayGain...
I would already be glad if we had support for the ogg replay-gain support (most of my soundfiles are ogg files anyway) and creating tags is best left to specialized tools anyway, so using the correct (available) tags is the only thing we need to care about.
And looking what tags have been added by the authoritative (available) tools for Linux will further trim the possibilities I guess.
As far as I understood, the difference between track gain and album gain is a technical one in the sense that you may want all tracks from the same album being 'leveled' based on all tracks (and not on a per track basis). For a classical CD or a rock concert, this is pretty much required.
I don't think these are different tags, just the value is based on different sources. So for playback (pytone) it doesn't really matter.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Hi,
On 18.07.05, Dag Wieers wrote:
On Sun, 17 Jul 2005, Joerg Lehmann wrote:
On 17.07.05, Stefan Wimmer wrote:
didn't you find anything in the HydrogenAudio Forums (http://www.hydrogenaudio.org/forums/)?
I found a link to that forum, however, didn't look around too much. Is it really necessary to search in an internet forum to get information about this "standard"? Oh well...
A little search on replaygain gave me a tremendous amount of hits :)
Yes, too many ;-)
I even don't know how to add ReplayGain tags to an mp3 file. There is mp3gain, which adds some tags but also changes the file itself. But this is obviously not what one wants - otherwise nobody would complain that PyTone doesn't support ReplayGain...
I would already be glad if we had support for the ogg replay-gain support (most of my soundfiles are ogg files anyway) and creating tags is best left to specialized tools anyway, so using the correct (available) tags is the only thing we need to care about.
And looking what tags have been added by the authoritative (available) tools for Linux will further trim the possibilities I guess.
That's what I was trying to do for MP3 files. However, I failed because I couldn't manage to bring the supposedly authorative tool mp3gain to insert tags (and not to adjust the whole file) ;-) And if somebody provide me with a pointer to a reference where I can find all this, it would really help.
As far as I understood, the difference between track gain and album gain is a technical one in the sense that you may want all tracks from the same album being 'leveled' based on all tracks (and not on a per track basis). For a classical CD or a rock concert, this is pretty much required.
I don't think these are different tags, just the value is based on different sources. So for playback (pytone) it doesn't really matter.
I think it matters. The idea is proably that when you play the whole album, you should use the album gain. Unfortunately that's not so easy to achieve. Suppose the following playlist
1. Album1/Track 1 2. Album2/Track 1 3. Album2/Track 2 ....
If we only look one song in advance, we will find that the first playlist item uses the track gain, the second one as well because it's from a different album, and when playing the third one, we realize that it's from the same album and that we had better taken the album gain for the previous song. But then it's too late...
And even, if we recognize albums correctly, we will have a different loudness of track 1 and 2.
So, it's probably impossible to do the correct thing when mixing album and single song playback and maybe the only solution is to ignore the album gain altogether.
Jörg
On Mon, 18 Jul 2005, Joerg Lehmann wrote:
On 18.07.05, Dag Wieers wrote:
I would already be glad if we had support for the ogg replay-gain support (most of my soundfiles are ogg files anyway) and creating tags is best left to specialized tools anyway, so using the correct (available) tags is the only thing we need to care about.
And looking what tags have been added by the authoritative (available) tools for Linux will further trim the possibilities I guess.
That's what I was trying to do for MP3 files. However, I failed because I couldn't manage to bring the supposedly authorative tool mp3gain to insert tags (and not to adjust the whole file) ;-) And if somebody provide me with a pointer to a reference where I can find all this, it would really help.
How did you verify that not only the tags were changed ? I'm now running vorbisgain through my whole collection of music and I don't know if it is doing more than just adding the tags :)
Did you dd parts of the file and checksummed them ?
As far as I understood, the difference between track gain and album gain is a technical one in the sense that you may want all tracks from the same album being 'leveled' based on all tracks (and not on a per track basis). For a classical CD or a rock concert, this is pretty much required.
I don't think these are different tags, just the value is based on different sources. So for playback (pytone) it doesn't really matter.
I think it matters. The idea is proably that when you play the whole album, you should use the album gain. Unfortunately that's not so easy to achieve. Suppose the following playlist
1. Album1/Track 1 2. Album2/Track 1 3. Album2/Track 2....
If we only look one song in advance, we will find that the first playlist item uses the track gain, the second one as well because it's from a different album, and when playing the third one, we realize that it's from the same album and that we had better taken the album gain for the previous song. But then it's too late...
And even, if we recognize albums correctly, we will have a different loudness of track 1 and 2.
So, it's probably impossible to do the correct thing when mixing album and single song playback and maybe the only solution is to ignore the album gain altogether.
Well, it would be already nice if we had 'radio' gain support. But an improvement would be if the algorithm could scan the remaining queue (if not empty) and verify if the next song(s) are from the same album when it starts playing a song.
In the unlikely event that this is the case, than it could switch to 'audiophile' gain support. Doing it like that makes sense to me.
In the cases where you want 'radio' gain support you're not planning to play a song from the same album in a row, so that's ok. And in the unlikely case that the random playback chooses a song from the same album (when you are in 'radio' mode anyway for a party or at home) it will not use 'audiophile' gain since the queue is empty at all times.
Does that make sense to you too ? :)
PS My previous description was wrong, sorry for the confusion. Like Stefan I pretty much agree that replaygain support is a requirement these days. It's annoying to have to adapt the volume from time to time.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Mon, 18 Jul 2005, Joerg Lehmann wrote:
That's what I was trying to do for MP3 files. However, I failed because I couldn't manage to bring the supposedly authorative tool mp3gain to insert tags (and not to adjust the whole file) ;-) And if somebody provide me with a pointer to a reference where I can find all this, it would really help.
I just found this:
http://www.hydrogenaudio.org/forums/index.php?showtopic=24527&mode=threa...
which explains to me what you mean. And as far as I can see there is no option to tell mp3gain to NOT change the mp3 file and just add the replay gain tags.
Which seems silly, because the beauty of replay gain is the fact that it is just a tag, nothing more complex than that.
But I don't see who this would matter for pytone. I wouldn't advice people to use mp3gain really, but if the tags exist pytone shouldn't care what mp3gain did, just act according to the tag.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Hi Dag,
On 20.07.05, Dag Wieers wrote:
On Mon, 18 Jul 2005, Joerg Lehmann wrote:
That's what I was trying to do for MP3 files. However, I failed because I couldn't manage to bring the supposedly authorative tool mp3gain to insert tags (and not to adjust the whole file) ;-) And if somebody provide me with a pointer to a reference where I can find all this, it would really help.
I just found this:
http://www.hydrogenaudio.org/forums/index.php?showtopic=24527&mode=threa...
which explains to me what you mean. And as far as I can see there is no option to tell mp3gain to NOT change the mp3 file and just add the replay gain tags.
Which seems silly, because the beauty of replay gain is the fact that it is just a tag, nothing more complex than that.
Great ;-) It's even better. MP3Gain adds information about the adjustment in so-called APE tags, which seems to be the de-facto standard for ReplayGain information [1]. Now I at least know, why my id3 tagging programs didn't show them... The only OS tag library which seems to be able to read APE tags is TagLib, at least in recent versions. There are Python bindings for this library, but I've not looked further whether they are of reasonable quality.
All this information can be found on the nice hydrogeneaudio wiki, which I just discoverd:
http://wiki.hydrogenaudio.org/index.php?title=Replaygain
But I don't see who this would matter for pytone. I wouldn't advice people to use mp3gain really, but if the tags exist pytone shouldn't care what mp3gain did, just act according to the tag.
I matters as far as PyTone has to be able to read the tag, and this is a bit tricky, as I've discussed above.
In the case of Ogg Vorbis, everything seems to be more clear. On the other hand, I do only have a couple of Ogg Vorbis files (I only use them for testing purposes), so my motivation is not too high to implement this feature without being able to use it by myself...
Jörg
[1] To make things even worse, LAME uses the mp3info header to store ReplayGain (actually only track gain) information. It seems that no player supports this so far. But probably, we could just ignore this "standard"
Hi,
Replying to myself...
I found some code in madplay (http://www.underbit.com/products/mad/), specifically in the file player.c, which could be useful as a basis for a Python implementation. I'll look a bit further in this, when I find some time. Volunteers are of course welcome, as well.
Jörg
On 20.07.05, Joerg Lehmann wrote:
Hi Dag,
On 20.07.05, Dag Wieers wrote:
On Mon, 18 Jul 2005, Joerg Lehmann wrote:
That's what I was trying to do for MP3 files. However, I failed because I couldn't manage to bring the supposedly authorative tool mp3gain to insert tags (and not to adjust the whole file) ;-) And if somebody provide me with a pointer to a reference where I can find all this, it would really help.
I just found this:
http://www.hydrogenaudio.org/forums/index.php?showtopic=24527&mode=threa...
which explains to me what you mean. And as far as I can see there is no option to tell mp3gain to NOT change the mp3 file and just add the replay gain tags.
Which seems silly, because the beauty of replay gain is the fact that it is just a tag, nothing more complex than that.
Great ;-) It's even better. MP3Gain adds information about the adjustment in so-called APE tags, which seems to be the de-facto standard for ReplayGain information [1]. Now I at least know, why my id3 tagging programs didn't show them... The only OS tag library which seems to be able to read APE tags is TagLib, at least in recent versions. There are Python bindings for this library, but I've not looked further whether they are of reasonable quality.
All this information can be found on the nice hydrogeneaudio wiki, which I just discoverd:
http://wiki.hydrogenaudio.org/index.php?title=Replaygain
But I don't see who this would matter for pytone. I wouldn't advice people to use mp3gain really, but if the tags exist pytone shouldn't care what mp3gain did, just act according to the tag.
I matters as far as PyTone has to be able to read the tag, and this is a bit tricky, as I've discussed above.
In the case of Ogg Vorbis, everything seems to be more clear. On the other hand, I do only have a couple of Ogg Vorbis files (I only use them for testing purposes), so my motivation is not too high to implement this feature without being able to use it by myself...
Jörg[1] To make things even worse, LAME uses the mp3info header to store ReplayGain (actually only track gain) information. It seems that no player supports this so far. But probably, we could just ignore this "standard"
-
Dag Wieers -
Joerg Lehmann -
Stefan Wimmer