search

leosongwei / mutagen

Automatically exported from code.google.com/p/mutagen
GNU General Public License v2.0
0 stars 0 forks source link

MP3: Replaygain values from LAME tag. #36

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
The following patch gives access to Replay Gain information obtained from
an mp3 file's LAME tag if present.

Usage example:
>>> import mutagen
>>> audio = mutagen.File('quiettest.mp3')
>>> audio.info.track_peak
0.040146470069885254
>>> audio.info.track_gain
23.400000000000002

Original issue reported on code.google.com by nondicti...@gmail.com on 5 Nov 2009 at 1:21

GoogleCodeExporter commented 9 years ago

Original comment by joe.wreschnig@gmail.com on 5 Nov 2009 at 3:51

GoogleCodeExporter commented 9 years ago 
The following revised patch contains a test which will run provided sox, lame, 
and
mp3gain are present. It also contains the original patch with a minor 
modification.

Original comment by nondicti...@gmail.com on 6 Nov 2009 at 3:58

GoogleCodeExporter commented 9 years ago 
Another patch, final one.

The test has been merged into test_mp3.py.
Track peak calculation code modified yet again to address portability concerns.

Original comment by nondicti...@gmail.com on 6 Nov 2009 at 3:24

GoogleCodeExporter commented 9 years ago 
This seems like a needlessly complex test. We aren't testing ReplayGain from 
first
principles - we're just testing whether Mutagen can read the tags LAME writes. A
couple of test files with known values would be a lot less fragile.

Original comment by joe.wreschnig@gmail.com on 7 Nov 2009 at 2:58

GoogleCodeExporter commented 9 years ago 
Another patch. This time the test is much simpler, however, during testing I
discovered an apparent bug in LAME where encoding a 64kbps mono file with 
22050Hz
sample rate would create a header frame that was one byte too small. This 
resulted in
me having to rewrite some additional code.

The mp3 files are for the data directory.

Original comment by nondicti...@gmail.com on 9 Nov 2009 at 11:42

Attachments:

GoogleCodeExporter commented 9 years ago 
Another revision. This one makes it possible to differentiate whether 
track_gain is
meant to be 0 dB or if that data is not available, in which case the value will 
be None.

Original comment by nondicti...@gmail.com on 14 Nov 2009 at 12:41

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by joe.wreschnig@gmail.com on 25 Nov 2009 at 12:02

GoogleCodeExporter commented 9 years ago 
Reading this patch now, it's extremely branchy. I think to get this logic in, 
the RG
parsing (and maybe the LAME/Xing/VBRI parsing in general) will need to be split 
into
a separate function, and not have so many possible execution paths.

Original comment by joe.wreschnig@gmail.com on 13 Dec 2009 at 4:14

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Rather than split apart methods of MPEGInfo, I have instead rewritten it 
entirely
from scratch.

The patch is against rev 73 and despite the rewrite incorporates the fix in 
issue 46.

A couple of unit tests had to be altered due to the way the patched version 
reports
the lengths of cropped files with VBR headers, and also the precise way in 
which VBR
headers are detected by the patched version.

Original comment by nondicti...@gmail.com on 8 Jan 2010 at 7:01

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm very nervous about a rewrite of this code, especially one that removes all 
the
docstrings and reference links.

I do not see the benefit of using a dict subclass to store frame information, 
since
frame attributes are not at all freeform.

Original comment by joe.wreschnig@gmail.com on 8 Jan 2010 at 7:46

GoogleCodeExporter commented 9 years ago 
A dict subclass was used for MPEGFrame so that MPEGInfo could pull out the 
values to
be made public with a one liner.

Original comment by nondicti...@gmail.com on 8 Jan 2010 at 8:29

GoogleCodeExporter commented 9 years ago 
Comments taken on board. Not sure how I can reassure though.

In addition this patch also reveals the VBR status which would close another 
issue if
adopted.

Original comment by nondicti...@gmail.com on 22 Jan 2010 at 9:32

Attachments:

GoogleCodeExporter commented 9 years ago 
Hi everyone, here's another take on the same subject, namely to give 
(read-only) access to LAME's ReplayGain and peak tags in MP3s. This patch does 
not do anything else, I tried to keep it as simple as possible. I also added a 
simple test case and an accompanying test file.

Original comment by Vitos.La...@gmail.com on 23 Jan 2013 at 7:24

Attachments:

GoogleCodeExporter commented 9 years ago 
mutagen has moved to Bitbucket: https://bitbucket.org/lazka/mutagen/issue/36

Original comment by reiter.christoph@gmail.com on 4 Jul 2014 at 3:41