bug-gnupod
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain


From: Frank Blendinger
Subject: Re: [Bug-gnupod] Patch to support ReplayGain / mp3gain
Date: Fri, 8 May 2009 12:14:53 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

Hey guys,

I'm very pleased to know you are working on ReplayGain support in
gnupod. I have just recently started to add ReplayGain tags to my music
collection, as mpd has started to support that. Now it seems I can also
benefit from this in my iPod, very nice.


On Thu 2009-05-07 21:16, Richard van den Berg <address@hidden>
proclaimed:
> On 5/7/09 5:06 PM, H. Langos wrote:
>> What's important is the fact that there seems to be a standard that defines
>> how volume adjustment data can be stored in id3 tags.
>
> Nice research. RVA2 is definitely the standard to use, and gnupod  
> already has support for it. The problem is that there is not a lot of  
> software that writes RVA2 tags. (The only ones I know about are iTunes  
> and normalize). mp3gain should really be changed to write RVA2 tags  
> instead of APE ones.

You might want to take a look at this python script:
http://mpd.wikia.com/wiki/Hack:ape2id3.py

It will read the ReplayGain settings from APE tags and add it to ID3v2
tags. It has worked without any problems for me so far.


>> So I wonder why the author of mp3gain decided to store the information in an
>> ascii APE tags comment instead of using the existing standard. (He 
>> definetly was aware of it as he states in the FAQ that he "uses David 
>> Robinson's Replay Gain algorithm to calculate how loud the file 
>> actually sounds to a human's ears.")
>
> mp3gain is one of  the first implementations of the Replay Gain  
> algorithm for mp3 files. Please note that the algorithm for calculating  
> the volume adjustment in itself has nothing to do with the way of  
> storing it. I think mp3gain predates the RVAD/RVA2 standards so they  
> went for an APE tag instead. It would have been nicer if they had stuck  
> it in a custom X??? ID3 frame instead. It would have been easier to port  
> it to RVA2 now.

This load of different tags is really annoying. I wish people would just
agree on a standard for things like this and stick to it, instead of
reinventing the wheel all over again. But I guess it's too late for that
already, as different players and devices are supporting different tags.

So to sum this up, we could have to deal with:
   * APE tags
   * RVA2 in ID3v2.4 or XRV/XRVA in ID3v2.3 or RGAD in ID3v2.3
   * iTunNORM as Comment in either ID3v2.3 or v2.4

Did I miss anything?

All of those could potential be present at once in a file. There can
only be either an ID3v2.3 or an ID3v.4 as far as I can tell. But there
can always be that iTunNORM comment in addition to the RG tags, and also
additional APE tags. I have actually seen files in the wild that have
all of this present. [1]

So how will gnupod handle this? I suppose the iPod will just use
iTunNORM and ignore anything else. Will gnupod use a present iTunNORM
comment or will it always create one from ID3v2/APE information?

What will be used if both ID3v2 and APE is present? I read about a
(possible?) --ignore-ape option, but I didn't really get what the
default behaviour will be. I, for one, would propose to use RVA2 if
present and APE only as a fallback, as it is more standardize and also
more often present in actual files, APE does not seem to be supported by
many (software) players (and I guess not by a single hardware device),
while some do support ReplayGain tags in ID3v2.


And one last thing: what about support for the music formats covered by
the gnupod_convert_* scripts? Those can carry ReplayGain tags, too, so
it would be nice to keep/convert them when the audio gets converted.

So far I only have experience with OGG Vorbis files. There is tool
similar to mp3gain called vorbisgain to calculate the gain data and
write the tags, and they can be read with the vorbiscomment tool. So I
guess it should not be that hard to read those tags as it is done with
the common artist/title/... tags and add them to the converted mp3
files.

I have read that there is also support for ReplayGain tags in FLAC
files, but I have no experience with that.


Greetings,
Frank


[1] I use this to check the files:
    For ID3:
        eyeD3 foo.mp3 | egrep -i '(gain|iTunNORM|ID3 v2)' -A1
    For APE:
        mp3gain -s c foo.mp3
    Is there anything nicer to do that? Do I miss any potential gain
    tags? I thought about putting together a small script to check all
    possible tags and show them in a nice format. Any hints/suggestions
    are welcome.

-- 
Frank Blendinger | fb(at)intoxicatedmind.net | GPG: 0x0BF2FE7A
Fingerprint: BB64 F2B8 DFD8 BF90 0F2E 892B 72CF 7A41 0BF2 FE7A

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]