mad-dev February 2004

mad-dev@lists.mars.org

6 participants
9 discussions

short imdct
by Rafael Ávila de Espíndola 26 Mar '04

26 Mar '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there any reason for not using the Szu-Wei Lee's algorithm for the short IMDCT (size 12)? Annexed is a patch witch implements it. Rafael Ávila de Espíndola -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAQO/RLlrfGJ8JUHwRAogGAJ9c8dZFc+vHM5SJ94FJGgJ8g2IJWQCfbyr5 qczH/qDxC7XBLkbkXn6mGcQ= =gjVQ -----END PGP SIGNATURE-----

2 1

#define CHAR_BIT 16
by Grigory A. 14 Mar '04

14 Mar '04

H! In my system minimum accessible variable is 16 bits wide. So I can use two technique I. Use low part of my 16 bits wide char. Use default #define CHAR_BIT 8 - this one working well. II. Try to use #define CHAR_BIT 16. This one has several problems 1. in decode_header() here sync: ... else if (!(ptr[0] == 0xff && (ptr[1] & 0xe0) == 0xe0)) { ... goto fail; } I solve it by else if (!((ptr[0] & 0xffe0) == 0xffe0)) it works. 2. III_huffdecode() function. I guess problem is here: // ---- align bit reads to byte boundaries ----- takes up to 32 bit ?? cachesz = mad_bit_bitsleft(&peek); cachesz += ((32 - 1 - 24) + (24 - cachesz)) & ~7; ... or here: if (cachesz < 21) { unsigned int bits; bits = ((32 - 1 - 21) + (21 - cachesz)) & ~7; ... It isn't work - at the middle of mp3 file I have MAD_ERROR_BADHUFFDATA So could you say to me these numbers: 32, 24, ... - what is the reason and how to calculate them for my case #define CHAR_BIT 16 ? And what I need to do more - to work with 16 bits wide char? Thanks for answers. -- Best regards, Grigory mailto:Ryhor@tut.by

2 1

Replay Gain
by Rob Leslie 25 Feb '04

25 Feb '04

I've been asked to elaborate a bit on Replay Gain and the issues surrounding it, as they relate to MAD and LAME. The Replay Gain proposed standard was set forth in 2001 by David Robinson and can be viewed here: http://www.replaygain.org/ First it's important to understand that Replay Gain has absolutely no bearing on the libmad proper; it doesn't affect the actual decoding process whatsoever, and libmad has no knowledge of Replay Gain structures or semantics. By cooperative agreement with encoders and other tools, applications can use Replay Gain information to adjust the volume of decoded audio to achieve approximately equal loudness across an entire collection of music. madplay does this when enabled with the -G (--replay-gain) option. The proposed standard describes a method for computing Replay Gain adjustments, which in any case are just decibel scalefactors. Essentially the energy of the encoded signal is calibrated against a reference level, and the difference is stored as the Replay Gain adjustment value. The reference level set forth in the proposed standard is the SMPTE-sanctioned 83 dB SPL, representing a comfortable average listening level. When Replay Gain is enabled, players are encouraged to supply a default pre-amp gain of at least +6 dB in addition to the Replay Gain adjustment. This is so pop music for example does not sound too quiet, but the pre-amp might be reduced or disabled for other types of music. madplay supports this with the existing -a (--amplify, --attenuate) option, which now has a default value of +6 dB when Replay Gain is enabled. Replay Gain information can be stored in a variety of possible locations, for example in an ID3v2 tag. Recent versions of LAME automatically compute Replay Gain data and store it in the LAME info tag: http://gabriel.mp3-tech.org/mp3infotag.html When enabled, madplay reads and honors Replay Gain from either of these locations. So what was the purpose of the changes in madplay 0.15.2b? It turns out that versions of LAME since 3.95.1 do not strictly follow the Replay Gain proposed standard. Instead of using the specified 83 dB SPL reference level (as LAME did in version 3.95) LAME now uses a reference of 89 dB SPL. That means the Replay Gain adjustment computed by LAME is now 6 dB greater than what is specified by the proposed standard, and players that implement the recommended pre-amp gain on top of that will amplify the signal too much -- and often cause clipping. Why did LAME do this? According to Gabriel Bouvigne, one of the LAME developers, "we had a discussion about it with David (ReplayGain author), and reached the conclusion that as the vast majority of implementations are using 89dB, we should take this infortunate situation into consideration and update the standard to 89dB." (But to my knowledge the proposed standard has yet to be updated.) The unfortunate effect of this heresy is that players have to know what reference value the Replay Gain adjustment was computed relative to, for it can no longer be assumed to be the 83 dB SPL specified in the proposed standard. Accordingly, special logic was added to madplay to detect LAME tags written since 3.95.1. And there you have it. Cheers, -- Rob Leslie rob(a)mars.org

1 0

madplay 0.15.2b released
by Rob Leslie 23 Feb '04

23 Feb '04

Aleksander Korzynski pointed out to me the recent LAME heresy with respect to Replay Gain: rather than using the 83 dB SPL reference specified by the Replay Gain proposed standard, LAME uses a reference of 89 dB as of version 3.95.1. Combined with the default pre-amp gain of +6 dB implemented in madplay, this often results in an over-amplified signal and clipping when Replay Gain is enabled. I've just released version 0.15.2b of madplay that compensates for this problem: ftp://ftp.mars.org/pub/mpeg/madplay-0.15.2b.tar.gz Cheers, -- Rob Leslie rob(a)mars.org

1 0

help output function
by Jorge ---- 20 Feb '04

20 Feb '04

Hi everybody, this is my first post, I'm a spanish student and I'm doing my final career proyect, this is a mp3 player and I'm using libmad. I'm studing the minimad.c but I dont know how the output function works, I've tried the mpg321 output function and it works better but I can't understand what it really do. It doesnt open /dev/dsp, does it? please I need I little bit of help thanks all Jorge Suarez-Solis Rivaya ___________________________________________________ Yahoo! Messenger - Nueva versión GRATIS Super Webcam, voz, caritas animadas, y más... http://messenger.yahoo.es

2 1

Suggested limits for madplay equalizer_filter and attenuate_filter functions
by Robert John Shepherd 20 Feb '04

20 Feb '04

Hi, In the equalizer.c and filter.c source for madplay, it seems to define no equalisation (flat) as MAD_F_ONE, but I couldn't find any documentation on what the upper and lower limits on this were, and whether this should be a linear scale. Also in attenuate_filter what is the maximum scalefactor? Any help appreciated, docs seem to be a bit mute on the subject. :/ Yours Unwhettedly, Robert John Shepherd. Editor DVD REVIEWER The UK's BIGGEST Online DVD Magazine http://www.dvd.reviewer.co.uk For a copy of my Public PGP key, email: pgp(a)robertsworld.org.uk

3 4

imdct36 CPU usage increase
by Derk-Jan Hartman 18 Feb '04

18 Feb '04

For some strange reason our latest version of VLC OSX more than doubles the CPU usage of mad_frame_decode, specifically the imdct36 routine it would seem. It is an OS X problem only and very annoying. Decoding mp3 now requires 28% CPU usage on my G4/400 (used to be 12%). libmad library version changes have been ruled out as the cause of this. Our mp3 decoder module didn't change either, but the demux module did change. We suspect it might be something like an alignment issue, but we can't seem to track it down.. Could you give some advice as to what might be the cause of this sudden increase in CPU usage, and how me may check some of our input for correctness? DJ --- Universiteit Twente Derk-Jan Hartman (d.hartman at student.utwente dot nl) http://home.student.utwente.nl/d.hartman

2 3

MAD suite 0.15.1b released
by Rob Leslie 18 Feb '04

18 Feb '04

MAD 0.15.1b is now available. Here is a summary of the important changes: libmad - New Layer III IMDCT routine based on Szu-Wei Lee's fast algorithm. - Improved robustness of Layer II bitrate/mode combinations. - Other improved portability and robustness. libid3tag - New id3_field_gettextencoding() API routine. - Other slightly improved robustness. madplay - New Replay Gain support (-G, --replay-gain). - Tags can now be shown without decoding any audio (-T, --show-tags-only). - New support for reading and displaying encoder tag information written by e.g. lame(1). For complete details, see the CHANGES file in each package as well as the updated man page for madplay(1). You will find the new releases here: ftp://ftp.mars.org/pub/mpeg/ Enjoy, -- Rob Leslie rob(a)mars.org

1 0

lost sync error still exist!
by zw_0000 09 Feb '04

09 Feb '04

I have comment the function related in mmap in config.h according Rob Leslie's suggestion, this method can resolve lost sync error! while I play any mp3 file in ARM machine, at 305 frames, lost sync occurs every time! why?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

mad-dev February 2004