Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.

Poll

It should be calculated once and stored in the Vorbis tags.
[ 183 ] (91%)
It should be calculated individually by each seperate player and not stored in the Vorbis tags.
[ 18 ] (9%)

Total Members Voted: 209

Topic: What is your stance on Replaygain support in Vorbis? (Read 22668 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

What is your stance on Replaygain support in Vorbis?

Reply #25
I see three problem areas right now:

a) Store data in files vs store data in players

A lot of reasons why storing data in the players hardly looks like the right solution were already given:

1) players need to add a database system (not likely for plugins, or stuff like ogg123)
2) ...and include all replaygain calculation code
3) all data gets duplicated between each player
4) if the user overrides a value, he has to do so in each player
5) for some players, the added complications may simple make it impossible to support (think portables! it's one area where having ReplayGain support would be _really_ useful)
6) why seperate essential information about the song from the song itself?

b) Store RG-data in tags vs store RG-data in metadata

I think this is a non-issue. I agree the RG-data belongs in the metadata, if it is possible to do so. There is no metadata standard for vorbis yet, and none is coming up for the near future.

I simply propose to store the data in the tags for now, and when the metadata actually becomes something else than vaporware, and you start adding support to the players and libs, you can switch over the RG tools to put the RG-data in the metadata.

When metadata gets added, all players, libs and tools will need to be updated to be able to make use of it anyway! At that point, it is no problem to change them to get their RG info from the metadata instead of the tags.

c) What tags should be stored

Monty had problems with the amount of data the RG proposal needs to store. He thinks it is possible to make everything work with storing just one value (radio gain).

(gets a bit technical here)

I think this is false. Firstly, not storing the peak tags, but instead taking clipping into account in the radio gain tag itself, makes it impossible to get the RG to work correctly. If the user decreases the preamp (=increasing the headroom) in the player, the song would no longer clip and we would be able to apply the correct gain. This is not possible in Monty's proposal - the loudness of the song cannot be corrected any more, because you don't know the exact gain that needs to be applied. You've thrown away this information already.

Inferring the album gain values from the individual file in an album is problematic in the players. Peter P indicated to me that WinAmp 2.x can't handle it, and that it would pose problems in WinAmp 3 as well. The same is true for XMMS and most players - they were never designed to handle something like this. If you're proposing something that can't be handled by the players, you've got a problem. You can't realistically expect them all to seriously modify their design just to handle this single issue. For playing a single file, you'd suddenly need to magically infer from the playlist which files belong to the same album, read them all in and parse all their tags, and then do the math to get the right album values. This is assuming correct album gain can be inferred from the seperate track gain values in the first place!

BTW. I would like David Robinson to comment on the latter.

If you look back at the original thread that started this debate, you'll see that this is exactly the reason why I felt the need to modify my proposal. Having to read in all tags of all files of the album you are playing is not possible in some players, and a needless complication in the others.

--
GCP

What is your stance on Replaygain support in Vorbis?

Reply #26
Really I'm not clear on what Emmett's definition of 'playback data' is - I don't think that it is an accurate characterization of RG data. The RG data describes the peak value contained in the file, the average loudness of the track, and the average loudness of the album containing the track. This is a gross simplification of course, but it is true that these values are static data directly associated with, and descriptive of, the contents of the file. Now the users' preference as to which of these values to use (radio vs album), how to use them (amount of extra headroom etc) are clearly 'playback data' and should not be stored with the file any more so than should (for example) a user's preferred EQ preset for playing back the file. Average and peak values, however, are intrinsic properties of the file contents, no less so than tile/artist/album etc, so I don't see how, even from a purist standpoint, they are inappropriate for inclusion.

What is your stance on Replaygain support in Vorbis?

Reply #27
Quoth Randum:

"Really I'm not clear on what Emmett's definition of 'playback data' is - I don't think that it is an accurate characterization of RG data. The RG data describes the peak value contained in the file, the average loudness of the track, and the average loudness of the album containing the track."

By playback data, I mean 'values that are passed to the player in order to give direction on how to play the audio contained therein.'

A tag like 'ARTIST: David Byrne' doesn't tell a player to play this particular track a particular way. It's a tag that identifies the artist of the audio contained in the file, and it's not a direction on where to set parameters in terms of playing that file. That's the difference.

Emmett Plant
CEO, Xiph.org Foundation

What is your stance on Replaygain support in Vorbis?

Reply #28
Quote
Originally posted by Emmettfish
Quoth Randum:
By playback data, I mean 'values that are passed to the player in order to give direction on how to play the audio contained therein.' 

Its a fine distinction I know, but I dont think that by this definition RG data is playback data. Yes, interpreted literally the RG data is saying "attenuate by Xdb", which would seem to be a 'direction on how to play the audio contained therein'... however when you realize that this 'direction' is simply a measurement of the difference between a property of the waveform itself, and a fixed value, really this is a measurement, i.e. description, not a direction. You COULD store the RG data as simply the average loudnesses, and leave it up to the player to do the calculation, based on this measurement, of how much attenuation to apply for a given RG or clipprotect mode. This data would be exactly equivalent to the RG data proposed to be stored, the only difference being that it has been reformatted to appear intuitively as a description of the waveform rather than a direction on its playback.

What is your stance on Replaygain support in Vorbis?

Reply #29
I'm glad Radium picked up on this fine point!

The title field says what the title of the track is.

The replay gain field says how loud the track is (well, kind of!).


The title field doesn't tell the player to display the title.

The replay gain field doesn't tell the player to change the volume.


However, this is being picky, but proves an interesting point: the RG data both is and is not playback data! It's not playback data, in the sense that it gives some information about the audio track that is true for that track, and (unless it's not actually correct) will never need updating. In this way, it's just like the title field. BUT whereas the information in the title field is useful on playback in that it can be sent to a display, the information in the RG field is useful on playback in that it can be used to change the audio data.


It's clear to me that the RG info should travel with the file, be it meta data or tag data. That was one of my main aims when I set up replaygain.org - to get this important (yet neglected) metadata into all audio formats. Audio Engineers spend a lot of time worrying about small improvements that most people will never notice - but most people will notice if one album is much louder than another, and it's about time we fixed it. It's also good to tie the data to a real world reference level, allowing the possibility of playing things at realistic volumes - but only 1 in a million people are going to care about this, so I don't push this point!


I've got a lecture - back soon.....

David Robinson.
http://www.replaygain.org/

What is your stance on Replaygain support in Vorbis?

Reply #30
I know it's been kindly said several times in the thread that the vorbis team should ask me what I think, but I'm probably the last person to ask (I'm probably about to prove this point with a long rambling post!).

I am very happy with the way others are taking the replay gain idea forward, and Garf has already said all the things that I would have added to the general discussion!


I'll make the following points, to add to the discussion about metadata vs tags. I realise that in practice the choice will come down to "whatever works", so this is probably pointless, but maybe it'll help... I appologise that I'm just repeating what others have said - but I'd like to back them up and say "I think you're right!"

0. tags ARE metadata. but I'll follow the convention that seems to have built up in this discussion that "metadata" means "some other area of data inside the file that's not a vorbis comment tag" when discussing this.

1. Store the four values. Just 1 value is (as Garf has explained) much less use - you need at least the "peak" value to go with it. Having track and album makes sense too. An intelligent player could infer the album peak from the playlist by checking each tracks "track peak" - but why not have that fourth value? It makes the players job easier.

So, if there's no space for four values in a vorbis header or metadata space, it'll have to go in the tags.

And have you thought of this point: If the format is released (which is kind is!), and then a meta data format is figured out later, people will NEVER use that new meta data part - they'll just stick everything in the tags as they always have done!


2. I think the RG values should be tied to the audio data as closely as possible. You need to be able to adjust them (in case they're wrong - the calculation isn't perfect!), but generally they should sit in the file along side the audio data, travel with the audio data (i.e. individual player-side storage solutions are a very bad idea), and not change.


3. Have you looked that the meta data provision in Meridian Lossless Packing (the DVD-audio format)? It includes the specification of an SPL reference (like the RG value) and Dynamic Range control information, information about what each of the 63 possible audio channels correspond to, and other stuff which is tied to the audio data (because it's packed with it in the same data stream). It's mainly information related to the playback of the audio, rather than stuff like title/artist etc. The Meta Data specification is open ended, and they thought about including it from day 1.

I can't find a great web reference for the meta data (I've read it somewhere, but now I can only find a small summary doccument with meta data at the end - http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF ) but it seems to be a well thought-out solution to the playback metadata needs of a 21st centurary audio format. You really should have the provision for something similar in vorbis! I appologise if it's already there.


I guess I'm coming down on the side of embeded meta data rather than tags for RG - but in truth, I don't think it matters either way! What does matter is that you should include human readable and editable type data, and machine readable type data, both in an open ended manner. The former you would propbably call "tags" and the latter you would probably call a "header" or "metadata".

To define the header (metadata) now, close the discussion, and (most importantly) not leave provision to add more is probably not wise. This, by necesity, would force any machine readable audio related information into the tags, which (I seem to recall) are supposed to be human readable. But there is obviously some data which should not be in the general human readable/editable tag area (e.g. number of audio channels!), and there may be more in the future which you haven't thought of yet! I think replay gain should probably go with this data.

Hope this helps. Sorry if it doesn't.

Cheers,
David.
http://www.replaygain.org/

web site not updated since last October - proving what a replaygain zealot I am! :-)

What is your stance on Replaygain support in Vorbis?

Reply #31
I'm late to this discussion, for I need to study first what ReplayGain is all about. I've never used it before, and now I know why--I listen mostly to classical music, and I've no use of RG.

But I've read through David's web site (to the best of my ability -- I'm a social science guy), and I've read the two recent threads about RG, which I ignored initially.

Still, I have some questions, and hopefully some of don't mind teaching a newbie a thing or two.

Question 1:

If the issue is about putting 4 tags in the user-definable Vorbis tags area, what exactly are you trying to get the Vorbis team to agree to?

Because classical music is my thing, I need quite a few extra tags on my ogg files. I need composers, opus no., original source (from piano rolls to 78 rpm to LP to CD), performers, orchestra, conductor... etc. I don't think I need any permission to create those tags, so if those RG tags are so important to you, why don't you just do it?

What does "official support" exactly mean in this context? You want the vorbis encoder (oggenc) to also do RG caculation and store the tags? Or you want the the libraries to provide functions to read/write the tags? Or you want the reference decoder to be RG-enabled? Or...?

Q2:

IIRC, the decoder has been freezed since RC1, right? The promise was a properly-implemented decoder/player now will be able to decode all future v 1.x files without problem, even if they're encoded with newer version of encoders. If we want the vorbis team to change the requirement so that only a RG-enabled decoder is a compliant decoder, they would have to break the promise, don't they?

This doesn't entail that they should never do it. But I think if this is really the case, their reluctance is at least understandable. Because it's they who have to go explain to everybody why they have broken their promise.

Q3:

Monty and Emmett never said this, so it could be just my imagination. But is it possible that there's a concern of loss of control? RG's development isn't under their control, and they might fear (legitimately, I think) that they'll have modify their specs again if something is changed on the RG front.

Q4:

About the number of tags. I don't really get why tags other than the track gain tag are necessary. Yeah, I understand the concept of maintaining the relative loudness between tracks within an album. But if you're really listening through an album, isn't adjusting the volume knob once enough for the whole album?

I guess I probably misunderstood something there, but my impression is that with those album gains, album peak, etc. you can listen through several albums without having to adjust the volume? Assuming that's correct, it's cool. But is it that important? To have three tags per file just to avoid tuning the volume once per album?

I guess some ideas are just hard for a non-RG fan to comprehend. I adjust volume depending on more factors than the loudness of the recording itself. It has to depend on the environment, time of day, what I'm doing, whether I'm wearing a headset or not...etc. I certainly can't program all these into the tags.

I do see the benefit of the track gain setting (radio mode), when playing mixed songs. But very little beyond that.

I guess all my questions circle back to the first one: if there's really nothing for the vorbis team to do except giving you their blessing, then there should be no problem at all. You write your own tools to write the tags, and ask player plugins or decoders to use them. You don't really need the permission of the vorbis team.

If some things need to be done on their part for this to be useful, then could someone explain Q2 to Q4 to me, please?

Frankly, I quite sympathize Monty and his team (how many people are there?). They've been swamped by demands. Some people want written specs, NOW! Some people want v 1.0, NOW! Some peole want very low bitrate encoding, NOW. Some people want even better audio quality, at even lower bitrate. Some peole wonder why they don't send an army of promoters to hardware player developers and give them their fix point encoder for free. And now this.

I don't know Monty, or Emmett, and I don't know how exactly they feel, but I certainly don't envy their jobs.
tw101

What is your stance on Replaygain support in Vorbis?

Reply #32
Quote
Originally posted by tw101

Question 1:

If the issue is about putting 4 tags in the user-definable Vorbis tags area, what exactly are you trying to get the Vorbis team to agree to?

Because classical music is my thing, I need quite a few extra tags on my ogg files. I need composers, opus no., original source (from piano rolls to 78 rpm to LP to CD), performers, orchestra, conductor... etc. I don't think I need any permission to create those tags, so if those RG tags are so important to you, why don't you just do it?

What does "official support" exactly mean in this context? You want the vorbis encoder (oggenc) to also do RG caculation and store the tags? Or you want the the libraries to provide functions to read/write the tags? Or you want the reference decoder to be RG-enabled? Or...?


Monty has said that he wanted ReplayGain support for Vorbis. I do not want a ReplayGain proposal that is not ok with the Vorbis people, because otherwhise work will be duplicated eventually and two implementations will exist. I want to avoid that.

ReplayGain does not really need support for the Vorbis side, but any given (officially standardize tags, support in libs) is very handy as it helps adoption.

Quote
If we want the vorbis team to change the requirement so that only a RG-enabled decoder is a compliant decoder, they would have to break the promise, don't they?


There is no need whatsover for a decoder to support ReplayGain in order to be compliant. It is a completely optional feature.

Quote
Monty and Emmett never said this, so it could be just my imagination. But is it possible that there's a concern of loss of control? RG's development isn't under their control, and they might fear (legitimately, I think) that they'll have modify their specs again if something is changed on the RG front.


What do you mean, outside of their control? They control exactly what Vorbis wants to support and what not. If they don't like a part of it, they don't have to use it. That's exactly why were having this discussion.

Q4 has already been answered in this thread. Moreover, if you have no use for RG, any of its features will seem useless to you. (sounds logical, doesn't it?)

Quote
Some peole wonder why they don't send an army of promoters to hardware player developers and give them their fix point encoder for free.


Paradox has done just that.

--
GCP

What is your stance on Replaygain support in Vorbis?

Reply #33
Quote
Originally posted by tw101
I don't think I need any permission to create those tags, so if those RG tags are so important to you, why don't you just do it?


That's what we've been doing. ReplayGain for Vorbis has been available for a couple of months now.

Quote
About the number of tags. I don't really get why tags other than the track gain tag are necessary. Yeah, I understand the concept of maintaining the relative loudness between tracks within an album. But if you're really listening through an album, isn't adjusting the volume knob once enough for the whole album? 

I guess I probably misunderstood something there, but my impression is that with those album gains, album peak, etc. you can listen through several albums without having to adjust the volume? Assuming that's correct, it's cool. But is it that important? To have three tags per file just to avoid tuning the volume once per album?


Not quite. In an album, the percieved volume of some tracks can intentionally be lower than that of others. When listening to a random playlist, one may wish to preserve that volume difference (I do).

The peak values aren't strictly required to get the "normalized playback" thing working. However, some tracks will have their playback volume raised. Since this is done by scaling the actual decoded sample values, there's the possibility that clipping is introduced (or increased), which can lead to audible artifacts. The peak values can be used to prevent this (by limiting the amount of volume increase).

Quote
I guess some ideas are just hard for a non-RG fan to comprehend. I adjust volume depending on more factors than the loudness of the recording itself. It has to depend on the environment, time of day, what I'm doing, whether I'm wearing a headset or not...etc. I certainly can't program all these into the tags.


True, but this limits the need to that only. E.g., you don't need to rush to the volume control when quiet song (or album) is followed by a compressed song.

Quote
I guess all my questions circle back to the first one: if there's really nothing for the vorbis team to do except giving you their blessing, then there should be no problem at all. You write your own tools to write the tags, and ask player plugins or decoders to use them. You don't really need the permission of the vorbis team.


For increased player support it is nice if this (optional) feature is supported by the core libs and tools, to make it even simpler to implement. And as has been said, the right place for this information isn't really the vorbis tags, but that's the best place that works now - and can be used as a stop-gap measure until a better solution is available (e.g., a metadata stream or special header fields).

Quote
Frankly, I quite sympathize Monty and his team (how many people are there?). They've been swamped by demands. Some people want written specs, NOW! Some people want v 1.0, NOW! Some peole want very low bitrate encoding, NOW. Some people want even better audio quality, at even lower bitrate. Some peole wonder why they don't send an army of promoters to hardware player developers and give them their fix point encoder for free. And now this.


But in this case we (2Bdecided, Snelg, Garf and me) have been doing most of the work, not them.

[span style='font-size:9'](Edit: Fixed two typos.)[/span]

What is your stance on Replaygain support in Vorbis?

Reply #34
Quote
Originally posted by Lear


That's what we've been doing. ReplayGain for Vorbis has been available for a couple of months now.


I knew that. Sorry if I didn't make myself clear.

What puzzled me was what you guys were up to by starting a poll here as if to put pressure on the Vorbis team to accept "something." Not that there's anything wrong with starting a petition, but  I just had trouble understanding what the "something" really is. What do you want them to accept?

Now, from you and Garf's explanation, I gather it comes down to this:

Quote
For increased player support it is nice if this (optional) feature is supported by the core libs and tools, to make it even simpler to implement.


You want RG functions to be part of the official library. But I wonder how much effort on their part has to go into this to make it happen. I understand you guys have been doing most of the jobs, up till now. But wouldn't it require quite some effort on their part if RG is to be supported by the official set of libraries and tools?

My biggest concern is, will this delay ogg vorbis's progress toward v 1.0 noticeably? There have been lots of talks that many big players in related fields (hardware manufactureres, CD mastering software companies like Ahead and Roxio, and other software vendors) won't even consider vorbis support until it hits 1.0. And there's been a lot of complaints for not seeing the specs, which Monty has promised to be delivered when vorbis hits 1.0. From my POV, it's more important to get there, and it might be a little too late to add RG without causing significant disruption.

Well. Just an opinion from an outsider. I certainly don't know how disruptive this will be, or how much effort is needed to incorporate RG into vorbis's libraries. Sorry if I didn't sound like too enthusiastic.
tw101

What is your stance on Replaygain support in Vorbis?

Reply #35
Quote
Originally posted by tw101

What puzzled me was what you guys were up to by starting a poll here as if to put pressure on the Vorbis team to accept "something." Not that there's anything wrong with starting a petition, but  I just had trouble understanding what the "something" really is. What do you want them to accept?


I did not start the poll, nor do I want to pressure the Vorbis team.

I want to know the reasons why they think the current proposal is no good. And I want arguments for it, so I can refute them one by one, or if that's not possible, alter my proposal.

I do not want them to 'accept' anything, just find out why they think the current proposal is good or not good.

Quote
You want RG functions to be part of the official library. But I wonder how much effort on their part has to go into this to make it happen. I understand you guys have been doing most of the jobs, up till now. But wouldn't it require quite some effort on their part if RG is to be supported by the official set of libraries and tools?


No, I will repeat again, if they don't want to, there is no need whatsoever to have library support for ReplayGain. ReplayGain works just as well without library support and is still trivial to implement without it.

The initiative of getting support in the libs has come from the Vorbis side, _not_ us.

The tools are already written.

Quote
My biggest concern is, will this delay ogg vorbis's progress toward v 1.0 noticeably? 


No. The limiting factor to getting 1.0 out is Monty finishing the encoder software. He is the only one with the needed knowledge. This is seperate from ReplayGain support, whose implementation can (and has been) done by others.

--
GCP

What is your stance on Replaygain support in Vorbis?

Reply #36
Quote
Originally posted by Garf
There is no need whatsover for a decoder to support ReplayGain in order to be compliant. It is a completely optional feature.


Ok, but how much different it is from the status quo then if it's optional. I mean, if you've got the tools and tags standardized, isn't it also up to the player/decoder developers to use it or not?

I guess I've some logical barrier to understand your position clearly. If it's as easy as adding an additional library to the vorbis library set, and its use is completely optional, then what's the difference from what you've got now?

If what you want is a greater degree of integration into the libraries and tools, then I would guess the integration needs quite some effort on their part, too. No? (My concern has been stated in my reply to Lear.)

Quote
What do you mean, outside of their control? They control exactly what Vorbis wants to support and what not. If they don't like a part of it, they don't have to use it. That's exactly why were having this discussion.


I mean further down the road. If they adopt your proposal and integrate RG into their tools and libraries. What if someday you (I mean you and other RG core developers) decide to make changes, what do they do? Yes, theoretically, they can keep what they have and refuse to implement your changes. But that isn't very realistic, isn't it? Once you've taken something in, it's hard not to follow its development.

Quote
Q4 has already been answered in this thread. Moreover, if you have no use for RG, any of its features will seem useless to you. (sounds logical, doesn't it?)


Well, I personally have no use for any of it, yes. But I can relate to the need of the radio gain (track gain) tag, while I have difficulty following what others are really good for. I mean, I do understand they'll be useful, but I doubt whether it's worth using 3 tags for that extra benefit.

If it's implemented in tags, I've no problem, for they don't bother me if I don't use them. But I'll be a little concerned if it's put into metadata (header) as some people suggested. Because that means it would bloat the header even if I don't use the feature at all. That's not to say I'll necessarily vote against it, though. Just concerned. But this is moot now since it seems you've abandoned the metadat route.

Quote
Paradox has done just that.


To one or a select few companies only, isn't it? There're still some hot air over on vorbis-dev mailing list, where people argue whether an independently developed free fix-point decoder would hurt Xiph's (potential) revenue. And some people are accusing Monty of trying to discredit the free deocodor in order to protect their own commercial interest, even though all Monty did was to clarify that a decoder capable of decoding RC3 files isn't necessarily compliant. Then he's further accused of withholding the specs (so no one know how to be fully compliant) in order to protect their own interest.

I understand the frustration of vorbis supporters of not being able to see the specs, but the discussion attests to Monty's pressure to get the thing out of the door asap.

Well, once again, please excuse the rambling of an outsider, who obviously knows much less than you guys.
tw101

What is your stance on Replaygain support in Vorbis?

Reply #37
Quote
Originally posted by tw101

Ok, but how much different it is from the status quo then if it's optional. I mean, if you've got the tools and tags standardized, isn't it also up to the player/decoder developers to use it or not? 

I guess I've some logical barrier to understand your position clearly. If it's as easy as adding an additional library to the vorbis library set, and its use is completely optional, then what's the difference from what you've got now?


I repeat, again:

There is no need to add an additional library to the vorbis set. The implementation works completely with the existing libs.

The initiative to get ReplayGain support into the Vorbis libs does _not _ come from us, but from the Vorbis side itself.

The Vorbis people _want_ ReplayGain support. There is a disagreement how it has to be implemented, and it must be ironed out so we do not end up with two competing implementations.

This is the only thing there is discussion about. All the rest are side issues. The discussion is not about ReplayGain support or not. It's about _how_ to implement it.

Quote
If what you want is a greater degree of integration into the libraries and tools, then I would guess the integration needs quite some effort on their part, too. No? (My concern has been stated in my reply to Lear.)


No, it does not. The support in the libraries is not necessary to work and the software has already been written.

Quote
I mean further down the road. If they adopt your proposal and integrate RG into their tools and libraries. What if someday you (I mean you and other RG core developers) decide to make changes, what do they do? Yes, theoretically, they can keep what they have and refuse to implement your changes. But that isn't very realistic, isn't it? Once you've taken something in, it's hard not to follow its development.


Nonsense. I repeat again: They control exactly what they support. If a certain feature would break backwards compatibility once the software gets spread out, they do not have to support it (and hence break their promise). Not to mention nobody on RG side is going to be inclined to introduce such a feature in the first side - it would break all work done to getting RG adopted up to that point.

Quote
If it's implemented in tags, I've no problem, for they don't bother me if I don't use them. But I'll be a little concerned if it's put into metadata (header) as some people suggested. Because that means it would bloat the header even if I don't use the feature at all. That's not to say I'll necessarily vote against it, though. Just concerned. But this is moot now since it seems you've abandoned the metadat route.


All of what you say here is completely senseless, since we do not even have an idea how the metadata will look or work in the first place. It does not exist yet. It is not even in development. There is nothing that says the metadata implementation won't be as flexible as the tag system is. (And hence won't waste space on things that aren't saved)

I haven't abandoned anything - there isn't anything to abandon yet in the first place.

Quote
To one or a select few companies only, isn't it? There're still some hot air over on vorbis-dev mailing list, where people argue whether an independently developed free fix-point decoder would hurt Xiph's (potential) revenue. And some people are accusing Monty of trying to discredit the free deocodor in order to protect their own commercial interest, even though all Monty did was to clarify that a decoder capable of decoding RC3 files isn't necessarily compliant. Then he's further accused of withholding the specs (so no one know how to be fully compliant) in order to protect their own interest.


This is a complete lie. Monty has explained _exactly_ what is wrong with the alternate fixed point decoders, and why they will break. The problem is that fixing the cause of that is a non-trivial programming exercise, and the author of the decoder is only interested in fixing it when it breaks.

The current fixed point decoders won't hurt Xiph's income - they're GPL, and hence unusable for most commercial companies. It has been explicitly stated it was GPL just for those reasons.

--
GCP

What is your stance on Replaygain support in Vorbis?

Reply #38
Quote
Originally posted by Garf
This is the only thing there is discussion about. All the rest are side issues. The discussion is not about ReplayGain support or not. It's about _how_ to implement it.


<backing away> Sorry if I misunderstood you, and sorry if I somehow offended you (for you seem quite irratated). I've never meant to impede anything.

My concern, from the POV of a user and vorbis supporter, is to see it reach the v1.0 finish line asap. And I raised some questions only because the issue was polled on the board, and I thought a wider range of input was solicitated. I didn't know the question was so narrowly defined. My apology. Ok? Please don't be offended.

Quote
This is a complete lie. Monty has explained _exactly_ what is wrong with the alternate fixed point decoders, and why they will break. The problem is that fixing the cause of that is a non-trivial programming exercise, and the author of the decoder is only interested in fixing it when it breaks.

The current fixed point decoders won't hurt Xiph's income - they're GPL, and hence unusable for most commercial companies. It has been explicitly stated it was GPL just for those reasons.


I'm not sure what "lie" you're referring to. From your explanation, you mean those accusations that I relayed in my previous message, right? Well, I was only relaying the sentiment on the mailing lists and some other boards where some people aren't happy with what Monty or other Xiph's people are doing.

I certainly didn't (don't) agree with them, and I believe I made clear that those accusations were false. I was using those accusations as an evidence of the pressure vorbis team is under. Nothing more. I meant no offense, and if I somehow managed to offend you, I'm sorry. Ok?

Hew!

p.s. I didn't vote in this poll, since the question is so technical. Don't count me as one of those who vote "no".
tw101

What is your stance on Replaygain support in Vorbis?

Reply #39
I didn't think my opinion would interest anyone... :-)

David.

P.S. when did adding 16 bytes (or whatever it is) to a 5MB file become "bloating"? ;-)

P.P.S. Thanks for all your work on this Garf. I'm sure millions of users will thank you one day! (soon, I hope).

What is your stance on Replaygain support in Vorbis?

Reply #40
Quote
Originally posted by 2Bdecided
I didn't think my opinion would interest anyone... :-)


Hehhh? Sorry, I really don't get this. Do you have anything to say, or not? (English isn't my first langauge. It's hard enough to get the literal meaning right, and to read into implied meanings, sarcasm, emotion, ...etc. is usually beyond me. Sorry.)

Quote
P.S. when did adding 16 bytes (or whatever it is) to a 5MB file become "bloating"? ;-)


Hmmm, many of my ogg files are far smaller than that. They don't use very high bitrate, and the tracks are short. (In classical music, some tracks are as short as less than 20 sec.)

And I didn't know how many bytes were needed. Looked to me the tag names alone took a lot of bytes. (Probably not necessary should they be implemented at the header leve, instead of tag. But I wasn't sure.) And frankly, I'm not sure how the header would look like if we all put things we think important there. If you ask me, there're more things that should go in there than RG.  (But that's just me. ok? I certainly know classical music listeners are in the minority.)

That being said. You're right, in general. 16 bytes (if that's all it takes) don't sound like many, and I take the word "bloat" back. Is that enough for peace?

Quote
P.P.S. Thanks for all your work on this Garf. I'm sure millions of users will thank you one day! (soon, I hope).


That I've no doubt. And I believe you and some others deserve credit, too.
tw101

What is your stance on Replaygain support in Vorbis?

Reply #41
tw101,

Don't worry - my sarcastic comment wasn't directed at you (or Garf)

Quote
--------------------------------------------------------------------------------
P.S. when did adding 16 bytes (or whatever it is) to a 5MB file become "bloating"? ;-)
--------------------------------------------------------------------------------

Hmmm, many of my ogg files are far smaller than that. They don't use very high bitrate, and the tracks are short. (In classical music, some tracks are as short as less than 20 sec.) 


That's a good point. I still doubt you'd notice it. AND (this being very important) no one will force you to include Replay Gain tags.

You're right - the ASCII tags take up more than 16 bytes - it would be more like 100. That's still only 0.1kB. Even if you have on average 1MB audio data per file, only 0.01% is going on RG info. Or to look at it another way, if you had 10000 very short audio tracks, the RG data in all of them put together would take up the space of 1 very short audio track.

But no one is forcing you to include them, unless I'm very mistaken. Adding the replay gain tags is a separate optional process.

Cheers,
David.

What is your stance on Replaygain support in Vorbis?

Reply #42
Quote
Originally posted by tw101

<backing away> Sorry if I misunderstood you, and sorry if I somehow offended you (for you seem quite irratated). I've never meant to impede anything. 

My concern, from the POV of a user and vorbis supporter, is to see it reach the v1.0 finish line asap. And I raised some questions only because the issue was polled on the board, and I thought a wider range of input was solicitated. I didn't know the question was so narrowly defined. My apology. Ok? Please don't be offended. 


Not your fault - I'm just extremely easy to get annoyed, and this debate has already gotten the better of me, so at this point I'm just barfing my annoyance at anyone who comes along, including you  Arf! Arf! [1]

It's your full right to comment on our doings - though I would prefer it if people commenting on this matter would carefully read what has already been written (replaygain.org/previous debates first), as it would clear up a lot. I'm specifically *cough* thinking of some Vorbis people here *cough*.

Quote
I'm not sure what "lie" you're referring to. From your explanation, you mean those accusations that I relayed in my previous message, right? Well, I was only relaying the sentiment on the mailing lists and some other boards where some people aren't happy with what Monty or other Xiph's people are doing.

I certainly didn't (don't) agree with them, and I believe I made clear that those accusations were false. I was using those accusations as an evidence of the pressure vorbis team is under. Nothing more. I meant no offense, and if I somehow managed to offend you, I'm sorry. Ok?
[/b]

If the accusations are false, the Vorbis team should not feel pressurized by them. The pressure for a spec _is_ grounded, and that's why it is high on their priority list. ReplayGain support is not critical. Which is why I'm not pressurizing for any official support. I am (or more, was) pressurizing for an agreement or at least sensible discussion, because that is important now. Competing specs would be no good.

Quote
p.s. I didn't vote in this poll, since the question is so technical. Don't count me as one of those who vote "no".


You are right - while Dibroms intentions where no doubt good, a technical decision like this shouldn't be based on a vote of which most voters will not understand all issues involved.

--
GCP

[1] Now you know where the handle comes from as well.

What is your stance on Replaygain support in Vorbis?

Reply #43
Quote
Originally posted by 2Bdecided

But no one is forcing you to include them, unless I'm very mistaken. Adding the replay gain tags is a separate optional process.


Correct. There is no overhead if it is not used, and if it is, it is very small.

--
GCP

What is your stance on Replaygain support in Vorbis?

Reply #44
Quote
Originally posted by Garf

You are right - while Dibroms intentions where no doubt good, a technical decision like this shouldn't be based on a vote of which most voters will not understand all issues involved.


To clarify, of course I agree with you.  The point isn't to bring about a decision based upon the poll itself.  Rather, I created to poll to exemplify the fact that there are a good number of people interested in this issue.  Both Paradox and segher had stated they had not received any emails on the topic at all and that this somehow implied there was very little interest in seeing this matter through, so it wasn't very important.  While it is true that in relation to many of the other items on the TODO list, replaygain isn't so critical, the notion that people are not particularly interested is not.  I wanted to show this and also drum up some more discussion and awareness of matters at hand here.  I think so far it has been a successful endeavor.

As for most people not understanding the matter properly, that may be true to an extent.  Certainly most people won't understand it in quite the detail (including *ahem* some of the people in #vorbis) that some like yourself would, but the issue as to whether the support should be on the player side or in the files themselves (via tags or metadata), is a pretty easy concept to grasp IMO.

What is your stance on Replaygain support in Vorbis?

Reply #45
Quote
Originally posted by Dibrom

To clarify, of course I agree with you.  The point isn't to bring about a decision based upon the poll itself.  Rather, I created to poll to exemplify the fact that there are a good number of people interested in this issue.  Both Paradox and segher had stated they had not received any emails on the topic at all and that this somehow implied there was very little interest in seeing this matter through, so it wasn't very important.  While it is true that in relation to many of the other items on the TODO list, replaygain isn't so critical, the notion that people are not particularly interested is not.  I wanted to show this and also drum up some more discussion and awareness of matters at hand here.  I think so far it has been a successful endeavor.


ReplayGain support is something that should no be underestimated. When I started working on it, I did more so because some people indicated that they wanted that feature before switching over to Vorbis, and because it was something I had the knowledge to program. At that time I had never used it myself (for MP3 or MPC). I was aware of the problem, but it had never occured to me it could be (and had been) solved.

The amount of feedback after publishing the first version quite surprised me. Looks like there are a _lot_ of people out there that use this crazy idea.

After starting to use it myself, I would not want to go back.

ReplayGain just needs to get better known to get more popular. Most people that don't use it do so because they don't know it yet, not because they don't like it or have no use for it. They've all encoutered the problem, but some live with it just because they don't know there is a solution.

Some weeks ago, I took a peek some weeks ago into a Belgian MP3 newsgroup too see what kind of stuff was being discussed there. Aside from the usual 37337 s(3N3 crap there was a complaint from someone that all those MP3's had a different volume and asked if there was a way to change the volume of an MP3.

One of the anwsers given to him was a pointer to MP3Gain, which, of course, immediately solved the problem completely and made for one more happy MP3 user.

At that point, I became completely convinced ReplayGain solves a real problem.

--
GCP

What is your stance on Replaygain support in Vorbis?

Reply #46
Well Garf, to tell you the truth I'd be very surprised if you can pull this Vorbis RG off someway in order to have Xiph's blessing.
I was discussing at #vorbis about this, and it just seems that the discussion there always gets heated, or someone always gets upset for whatever reasons.

Anyway. What I gathered is that there's even conflict inside Xiph how RG should be implemented. Emmett would go for metadata, while Jack doesn't want RG even into metadata.
Emmett cares about RG but said that he doesn't care about it in large scale. Jack says he cares about RG, but I have no idea how much.

All in all, the situation even inside Xiph is not clear regarding RG. One thing they agree though is "not right now, maybe later".

My opinion is that your current suggestion won't get support from Xiph.
Juha Laaksonheimo

What is your stance on Replaygain support in Vorbis?

Reply #47
Quote
Originally posted by JohnV

All in all, the situation even inside Xiph is not clear regarding RG. One thing they agree though is "not right now, maybe later".

My opinion is that your current suggestion won't get support from Xiph.


Yes. It is time to lay this discussion to rest. There will be no official support for ReplayGain for the time to come, both because of disagreement on all fronts about the how and because of a lack of complete infrastructure and time and willingness.

The unofficial support will get improved via the revised proposal.

At the time the Vorbis team works out their own official support, we can drop the unofficial support. At least there will be incentive to make the official support work at least as good as the current unofficial one.

--
GCP