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.
Topic: MP3Gain 1.1 Beta (Read 21441 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MP3Gain 1.1 Beta

Reply #25 –
Yes, there is space reserved in Lame header for those info:
* replaygain peak value
* replaygain radio adjustement
* replaygain album adjustement
* mp3gain potential modification

http://gabriel.mp3-tech.org/mp3infotag.html

Right now (3.94 alpha), Lame stores the peak and radio values. It seems to me that mp3gain could use the stored peak and radio values to save the analysis time, and could store the modification value into the mp3gain field

MP3Gain 1.1 Beta

Reply #26 –
Quote
Quote
yes I believe ID3v2 support would be the perfect solution!

I hope that's really optional, since don't use tags and remove any and all tags from MP3s that have them. I wouldn't want the MP3gain tags to fall victim to that...

Same here, I don't use tagging, and remove all id3v2 tags. Ideally, mp3gain would fill in replaygain values in the Lame header if present, and add a Lame header if not present yet...

And I think that the few initial reports about Lame tags causing any trouble died out by now?

MP3Gain 1.1 Beta

Reply #27 –
Quote
Quote
Quote
yes I believe ID3v2 support would be the perfect solution!

I hope that's really optional, since don't use tags and remove any and all tags from MP3s that have them. I wouldn't want the MP3gain tags to fall victim to that...

Same here, I don't use tagging, and remove all id3v2 tags. Ideally, mp3gain would fill in replaygain values in the Lame header if present, and add a Lame header if not present yet...

And I think that the few initial reports about Lame tags causing any trouble died out by now?

I would also like replaygain info stored in the lame tag, as I have asked for In the past...

MP3Gain 1.1 Beta

Reply #28 –
Quote
Same here, I don't use tagging, and remove all id3v2 tags. Ideally, mp3gain would fill in replaygain values in the Lame header if present, and add a Lame header if not present yet...

I do use tags, but remove id3v2 tags.
If you add a Lame header you get i.e. Xing (or fhg) files with a Lame header. Wouldn't that be more confusing?
APE2 seems like the near future (for mp3).
--
Ge Someone
In theory, there is no difference between theory and practice. In practice there is.

MP3Gain 1.1 Beta

Reply #29 –
The Lame header is in fact a INFO header, that could be used for any encoder.
But I'm not sure if adding an Info tag after encoding to files generated by other encoders would be good.

Perhaps ability to store values into the Info header if present and if not adding an ape2 tag?

I think that it would be nice if mp3gain could use the value stored into Info tag instead of computing it once again. That would save a lot of time.
 

MP3Gain 1.1 Beta

Reply #30 –
Thoughts:

Storing Replay Gain values with more than 1 decimal place is pretty silly. More than 2 is just plain stupid. Really. It's just like having a broken calculator which you know doesn't usually get the answer correct to the nearest whole number, let alone several decimal places - but writing down the answer it gives you to 6 decimal places anyway! It won't do any harm, but it won't do any good either. And it may make people think that those decimal places are significant - they're not. At all. Ever.

The peak values are different - these need to be 16, 24, or even 32-bit accurate (in theory) for some applications


There should be 1 - just 1 - way of storing the replay gain data in an mp3 file. The Lame tag way seemed like a good idea at the time, but in retrospect, it seems like a mistake. It made sense for lame created files - but what about other mp3s? Adding tags at the start of an already created file is silly - they should go at the end. That's just common sense. Having one way of adding replaygain info for lame files, and another for all others is also silly. So it's better to put it at the end, and only the end.


Though I originally suggested ID3v2 as a way of storing replay gain info in mp3s, nothing uses this (to my knowledge). It would be very sensible to decide, now, once and for all, that the correct place for replaygain info in an mp3 is in an Ape 2.0 tag at the end. If it scares people to talk about yet another format, just call it the replay gain tag. Those in the know will know what's happening - others will be happy.


The only prolem is that some tools will report it as a corrupt frame. But if they didn't understand ID3, they'd report that as a corrupt frame. If they didn't understand Lyrics3, they'd report that as a corrupt frame. So, the answer is simply to update these tools. If the answer was always "do not put anything in that existing tools won't understand", then Lyrics 3 and ID3 could never have been invented. The replay gain tag (i.e. replay gain info in an ape 2.0 tag) is backwards compatable with players, because they'll just ignore it, so there's no actual problem.



In conclusion (!) my suggestion is this:

Store replay gain values in an Ape 2.0 tag near the end of the file.
For newbies, just refer to it as the "replay gain tag".
Use whatever number of decimal places you like - one is more than enough!
If someone complains that the "replay gain tag" is being reported as a corrupt file, just say "the file checking tool doesn't recognise the replay gain tag yet - it'll get updated eventually".
If someone asks why replay gain info isn't in ID3v2, say
1) no player supports it
2) some players do support the replay gain tag, and other are encouraged to do so
3) Some players choke on ID3v2
4) No players choke on the replay gain tag - it does no actual harm
5) Many people strip ID3v2 tags or re-create them on mass from file names - this would destroy replay gain info!
6) Only tools that understand replay gain will touch the replay gain tag, so it's safe.


That's my opinion. Feel free to ignore it. I'm only guessing Ape 2.0 tags have no compatibility problems - can someone confirm this?

I hope Ape 2.0 tags become more widely used - if so, some of the points above would become false (i.e. people will strip them!), but then more tools will correctly recognise them. It's a pity ID3v2 came first - hardware devices support this that will never support APE 2.0 - though hopefully some will support at least the replay gain part, and maybe the rest of it, eventually.

Cheers,
David.

MP3Gain 1.1 Beta

Reply #31 –
I am not opposed to apev2 tags at the end. After all, what is important is to have a way to read the gain values, and to rollback the changes.

I'd just like mp3gain to be able to read the already computed values stored into Lame tag.

MP3Gain 1.1 Beta

Reply #32 –
I know this sounds unreasonable, but is there anyway to remove RG from the lame tag now? Seriously. If Lame is going to calculate RG values, can it store them the same place as mp3gain? And only there? please?

Does anything actually use the RG values in the lame tag? Because, if not, now would be a great time to drop them. Permanently.


Otherwise, every subsequent software or hardware device that wants to find RG values in mp3s will have to look in two places. This just seems so stupid!



This is only a suggestion. I can imagine that it won't be popular. But is there any reason why it is not sensible?

Cheers,
David.

MP3Gain 1.1 Beta

Reply #33 –
Well, I am very surprised. There has been a place reserved for RG values in the Lame tag since the beginning, and only now there are some concerns about it.

Right now there is now way to remove those values (except with an hex editor).

Do you think that this is a bad thing for the encoder to compute the RG values?

I am not sure if it would be a good thing for the encoder core to store an other tag structure. If you really want an ape2 tag, perhaps what we need is a converter. (That is why I suggested that mp3gain could read those values from the Lame tag if present. It could still store it into an ape2 tag)

You could also decide to completely ignore what is inside the Lame tag, but this would probably be the worst choice.


Perhaps it would also be the right time to start a deeper thinking about tags and containers.
Right now we have:
id3v1: supported by about every program
id3v2: supported by hardware players, standard winamp decoder, itunes
ape2: supported by foobar, winamp mpc/ape plugins
XING/Lame tag: supported (partially) by winamp standard decoder, probably supported by Real
VBRI: supported by FhG.
mp4: supported by apple tools

Perhaps ape2 are wise, but I immediately see 2 problems:
*placed at the end, could be a problem for hardware players
*The name. How would you expect FhG to accepte something with such a name? (I know, the problem is the same with the Lame name)

MP3Gain 1.1 Beta

Reply #34 –
You make a good point - one that I've thought about, and got nowhere with.

I was thinking about it in the context of replay gain, and decided that the best way was for it to have it's own "tag". This seems stupid (enough tag format already), but none of them are ideal. ID3v2 breaks some players. ID3v2 is usually at the start of the file (that's terrible for updating on HDD). ID3v1 doesn't have enough room. Lame tag is a good concept, but it isn't widely supported, and it makes no sense to add it to other files. It should contain lame specific things, not general things!

I'm sorry to put forward this surprising idea. I know RG was in there from the start - it was the idea of including some kind of volume thing in the lame tag that made me put ReplayGain together. However, in retrospect, it seems like the wrong place for the information.


Tags: I'm not qualified to comment on this, so flame away... I've heard of (but not used) a version of ID3v2 which is stored at the end - there's a small header block at the start of the file which points to the main tag at the end. If the header block is 100% compatable with all mp3 players, and if the header block size can remain unchanged even when the tag itself is changed, and if ID3v2 data stored in this way is compatable with all existing ID3v2 devices (especially hardware players) then this seems like the best solution. However, I don't know the answer to all these "if"s.

There's also work in Mpeg 7 which may or may not be relevant. Storing metadata (i.e. data about data) is a big headache because so many existing formats don't have it defined, and those that do all have individual ways of doing it.

A globally understood metadata block format which can work with all formats (e.g. wav, mp3, mpc, ogg etc maybe even CD-DA), can be transferred between formats (so encoding or decoding or transcoding simply requires the meta data block to be copied, with a small update), and can be automatically identified and sent first (even though it's stored last or separately or whatever) whenever files are shared or streamed - that's the dream. Of course, everyone has to support this one standard. We're good at that, humans, aren't we? Picking a world-wide standard and sticking to it?  NTSC/PAL/SECAM, driving on the right or left side of the road, etc etc etc!

Cheers,
David.

MP3Gain 1.1 Beta

Reply #35 –
On the other hand, tags stored at the end are a draback for hardware devices: seeking at the end means more power used, and so less battery life.

I really think that we have to initiate a discussion about tags and what should be inside those.
It seems to me that inside the Lame tag, we mixed 2 things:
*internal info: preset used, lowpass value, ath used, vbr mode,...
*player related info: codec delay, replaygain values, seek table, surround mode,...

There is also a third category, which is user related: track name, track author, album name,...

Perhaps the player related ones could even be splitted between player related and decoder related:
*decoder: seek table, codec delay
*player: replaygain values, surround modes

MP3Gain 1.1 Beta

Reply #36 –
TBH, looking at it again, the whole thing makes my head spin.

I don't like tags at the start of files because adding or updating+extending them means re-writing the whole file. I don't like tags at the end of files because the data is the last thing to be transferred in p2p, and, as you say, means a double seek when playing the file. I certainly don't like data stored (only) separately from the file because it will get lost.

If you have mp3+cue or mpc+cue (or any other instance where you have a ~100MB lossy file) the first problem is not trivial - it makes changing tags very slow!

If you're downloading a file, it's annoying having the info at the end - especially if it's info that would make you stop the download - e.g. encoding quality (or lack of), recording version etc etc

The logical compromise seems to be an all-player compatable fixed length tag at the start which is written (maybe partly blank) by all mp3 encoders, and filled with a fixed amount of information. Then there can be an extensible, variable length tag at the end which can hold all other information. The problem is: what is important enough to put at the start, and what is trivial enough to leave until the end? Who decides, and how?

The best answer to this is maybe to say: OK, it's a 4kB (say) block at the start - always. This is universally fixed - mp3s should start with a block this size - always. It's in ID3v2 format. What you decide to put in there (and what you decide to leave for the variable length tag at the end of the file) is up to you. You get the best of both worlds. Or maybe the worst!

Can this be done in a compatible way?

Cheers,
David.