mad-dev

mad-dev@lists.mars.org

682 discussions

Progress meter
by Hamish Allan 30 Apr '04

30 Apr '04

Hi folks, I've just started writing an audio processing utility, using libmad to read from MP3 files. I've modelled my code on minimad.c and it works fine, but as I'm decoding each file all at once, I want to provide a progress meter. In minimad.c the whole file is mmapped, so the read function only gets called once. I figured I would change my read function to make available a small fraction of the data, update the progress bar, then make the next block available, etc. Unfortunately this doesn't work, I get "lost synchronisation" , "reserved sample frequency value", "bad main_data_begin pointer", "forbidden bitrate value" and "Huffman data overrun" errors each time I return a new block of data. As far as I can tell, my code is doing the right thing (I've included it below). In madllc.c, there is provision for when a frame is not wholly included by a buffer, but I would expect in the case of the high-level functions that this would be detected by mad_decoder_run and the input function would be polled for more data automatically. Am I missing something obvious? Also, is there a better way to implement a progress bar? Thanks in advance, Hamish P.S. this code is in Objective-C: "[inputData length]" does what the C++ "inputdata.length()" would do, and "id" is like "NSObject *" (NSObject is the root object). struct dataDescriptor { NSData *inputData; NSMutableData *outputData; unsigned int bytesRead; unsigned int byteChunk; // number of bytes to read at a time id progressObject; }; static enum mad_flow madInput(void *data, struct mad_stream *stream) { struct dataDescriptor *descriptor = data; NSData *inputData = descriptor->inputData; unsigned int bytesTotal = [inputData length]; unsigned int bytesLeft = bytesTotal - descriptor->bytesRead; double progress = (double)(descriptor->bytesRead) / (double)bytesTotal; [descriptor->progressObject showProgress:progress] if (bytesLeft == 0) return MAD_FLOW_STOP; fprintf(stderr, "Bytes read=%d, left=%d\n", descriptor->bytesRead, bytesLeft); if (bytesLeft > descriptor->byteChunk) bytesLeft = descriptor->byteChunk; mad_stream_buffer(stream, [inputData bytes] + (descriptor->bytesRead), bytesLeft); descriptor->bytesRead += bytesLeft; return MAD_FLOW_CONTINUE; }

2 1

Reordering question
by Grigory A. 21 Apr '04

21 Apr '04

Hi! MAD for sp3r5m 3DSP core www.3dsp.com is ready. In average up to 256 kb/s 27MHz is more than enough to decode any mp3 bitstream. But 320 kb/s - required calculation is very close to available resources (and maybe even worst) Only - I want to improve performance in some places Now I am looking on void III_reorder(mad_fixed_t xr[576], struct channel const *channel, unsigned char const sfbwidth[39]) C implementation takes ~30 000 cycles - it is too much. So could you tell me can I use for reordering this one simple scheme for sb=0 to 31 do //For all 32 subbands for window=0 to 2 do //For each of the 3 windows for ws=0 to 5 do //For each sample within a window Xro[18*sb + ss] = Xdis[18*sb + window + 3*ws] //Reorder end for end for end for If answer is "no" - so could you explain the role of unsigned char const sfbwidth[39] in original MAD reordering function very shortly of course. Thanks for answers -- Best regards, Grigory mailto:Ryhor@tut.by

2 1

save PCM
by Гурин Олег 18 Apr '04

18 Apr '04

Hello. Why do I get PCM with loud noise while decoding? I receive Mp3 stream using HTTP. After mad_synth_frame I record 16-bit values on disk (as in the madlld example). During playback of the PCM obtained the music itself can hardly be heard because of noise ? (Win 2000 platform, libmad ver.0.15.1) --- Ваш легкий поиск ТУТ! http://go.tut.by

2 1

huffman.c macros
by Ian MacIntosh 14 Apr '04

14 Apr '04

I was building this on Solaris and noticed the macros for PTR and V only work for little-endian or gcc compilers. So I made a few changes, below are the macros rewritten for more portability: for huffquad # if defined(__GNUC__) || (__SUNPRO_C >= 0x556) # define PTR(offs, bits) { .ptr = { 0, bits, offs } } # define V(v, w, x, y, hlen) { .value = { 1, hlen, v, w, x, y } } #elif defined(WORDS_BIGENDIAN) # define PTR(offs, bits) { { 0, bits, offs } } # define V(v, w, x, y, hlen) { { 1, hlen, (v << 11) | (w << 10) | \ (x << 9) | (y << 8) } } #else # define PTR(offs, bits) { { 0, bits, offs } } # define V(v, w, x, y, hlen) { { 1, hlen, (v << 0) | (w << 1) | \ (x << 2) | (y << 3) } } # endif for huffpair # if defined(__GNUC__) || (__SUNPRO_C >= 0x556) # define PTR(offs, bits) { .ptr= { 0, bits, offs } } # define V(x, y, hlen) { .value= { 1, hlen, x, y } } # elif defined(WORDS_BIGENDIAN) # define PTR(offs, bits) { { 0, bits, offs } } # define V(x, y, hlen) { { 1, hlen, (x << 8) | (y << 4) } } # else # define PTR(offs, bits) { { 0, bits, offs } } # define V(x, y, hlen) { { 1, hlen, (x << 0) | (y << 4) } } # endif instead of the ptr: and value: it uses the C99 designator syntax, also I've changed the shifts for big-endian. obviously the WORDS_BIGENDIAN needs to come from the config.h. regards, Ian

1 0

Intensity stereo
by Grigory A. 12 Apr '04

12 Apr '04

Hi! Could someone give me or tell where can I take mp3 bitstream with joint stereo Intensity_Stereo_LSF_EXT all other bitsreams have been successfully tested. Only this one is question. If in MAD decoder there is such portion of code - I think it is tested. Thanks. Best regards, Grigory mailto:Ryhor@tut.by

1 0

unsusbcribe
by Alain 02 Apr '04

02 Apr '04

unsusbcribe ___________________________________________________________ WIN FREE WORLDWIDE FLIGHTS - nominate a cafe in the Yahoo! Mail Internet Cafe Awards www.yahoo.co.uk/internetcafes

1 0

Starting/stopping decoding of same stream
by Erik Jälevik 30 Mar '04

30 Mar '04

Thanks to Rob and Tony for the answers to the channel question. I'm trying to implement a class within my C++ app that presents a stream interface to the MAD decoder, i.e. it does buffering and provides a Tick() method that returns the next decoded sample in the stream as a floating point number. My first attempt uses the high-level API but I've stumbled on a problem I can't seem to get around. The logic I'm using in Tick is something like the following: 1. Check PCM buffer. 2. If data present, just return next sample. 3. If buffer empty, go away and decode some more to fill buffer. 4. When buffer is full, stop decoding and return first sample in buffer. I need to stop and start decoding the same stream at regular intervals depending on the PCM buffer size. So at stage 3 above, I call mad_decoder_run on the properly initialised decoder, and in the output callback, I return MAD_FLOW_STOP when I've been given enough frames to fill the buffer. Up until now everything's fine. But, it seems that the next time the buffer gets empty and I restart by calling mad_decoder_run again on the same decoder, the decoder doesn't remember the input last given to it by the input callback. So the first thing it does is call the input callback for more input. The mad_stream->next_frame passed into the input callback is always 0 after a restart. This causes problems because the input callback has no way of knowing how far into the previous chunk MAD has decoded. Is there any way to find this out from the decoder itself? I haven't looked at the low-level API yet, will I maybe need to use that to achieve what I want? Hope the above makes sense, I've only just started using MAD so might have overlooked something blindingly obvious. Many thanks, Erik

4 8

RE: Re[4]: [mad-dev] III_requantize() accuracy
by Tony Francis 27 Mar '04

27 Mar '04

Hello Gregory, In the link that you had provided, they are talking about the output pcm bit width and not about the fixed point data width. And some use floating point Math. But I couldn't understand the logic why you have to stick to 4.28x1.31 alone. One thing I always thought was why it was necesssary that you should stick to 4.28 * 4.28 giving 4.28 itself. I can have some thing like 4.28 * 2.30 giving 5.27. After all your maximum pcm bit width at output is 24 and 27 fractional bits will give you the same effect as 28 fractional bits. I had worked on a 3DSP processor some 3 years before but I don't remember any thing about it. How is the multiplier in 3DSP? I remember it as a 32 bit processor and I think there was a multiplication instruction which gives you the upper most 32 bit result of a 32 by 32 multiplication and is this the reson why you wants 4.28 by 1.31 multiplication? One more thing accuracy test is to be done only for compl.bit in ISO test streams I believe. Have a nice week end. Cheers, Tony -----Original Message----- From: Grigory A. [mailto:Ryhor@tut.by] Sent: Friday, March 26, 2004 1:49 PM To: Tony Francis Cc: mad-dev(a)lists.mars.org Subject: Re[4]: [mad-dev] III_requantize() accuracy Hello Tony, Friday, March 26, 2004, 2:53:52 PM, you wrote: TF> With 16 bit implementation on TI55x how much accuracy you got? And TF> how much accuracy improvement was there by changing the TF> multiplication into 4.28 by 1.31 instead of 4.28 by 4.28 used in MAD TF> decoder? According to http://www.underbit.com/resources/mpeg/audio/compliance/ in best case limited accuracy is achieved. But in worst case ... rms still C*10^-4 but C - is bigger than limited accuracy require. 4.28x1.31 - I just have to use this one :) This is 3DSP hardware dependent - in another case - like 4.28x4.28 I need to do additional actions... So almost in all places decoder use constants less than 1.0 Only in synthesis part some of them are bigger than 1. But now I am working under synthesis and I am looking in way where constant which are bigger than 1 will be split on 2 part. After I finish decoder we can measure accuracy :). -- Best regards, Grigory mailto:Ryhor@tut.by

2 1

RE: Re[2]: [mad-dev] III_requantize() accuracy
by Tony Francis 26 Mar '04

26 Mar '04

Hello Gregory, With 16 bit implementation on TI55x how much accuracy you got? And how much accuracy improvement was there by changing the multiplication into 4.28 by 1.31 instead of 4.28 by 4.28 used in MAD decoder? I am not very sure whether a floating point version of MAD is there, but if not what about creating one? Some RISC processors have fpu now and it may be of interest for some. Cheers, Tony -----Original Message----- From: mad-dev-admin(a)lists.mars.org [mailto:mad-dev-admin@lists.mars.org] On Behalf Of Grigory A. Sent: Thursday, March 25, 2004 7:06 AM To: Rob Leslie Cc: mad-dev(a)lists.mars.org Subject: Re[2]: [mad-dev] III_requantize() accuracy Hello Rob, Wednesday, March 24, 2004, 7:12:59 PM, you wrote: RL> Keeping in mind that 2^(-36.75) = 2^(-36) ? 2^(-3/4), you will find RL> that III_requantize(210, -147) calculates: RL> 210^(4/3) ? 0x04e0393e ? 2^12 RL> 0x04e0393e ? 2^(-36+12) ? 0x00000005 RL> 2^(-3/4) ? 0x09837f05 RL> 0x00000005 ? 0x09837f05 ? 0x00000002 RL> I think the difference is due to rounding errors from the limited RL> precision of the fixed-point type. You're talking about a difference of RL> 3.725e-9, pretty insignificant in the grand scheme of things. RL> If you configure with --enable-accuracy, you'll get a slightly RL> better fixed-point multiplication in the last step that happens to RL> yield the value you were expecting. Yes I am agree. Only one difference in my calculation scheme I firs multiply on root - in this case 2^(-3/4) and next rounding and shifting. This small changes give more precise result. And why I am talking about it. Now I am "porting" MAD 0.15 to 3DSP platform www.3dsp.com this is 32 bits dsp with 32x32 multiplier - so I am expect good result. Now at my decoder differences after III_requantize() are +-1 only - but at synthesis time sbsamples have +-25 with average rms ~1.2e-8 compare to MAD. My calculation is performed in 4.28x1.31 format - so error coming from this last bit in 4.28 representation of Xr data. And - I have working "MAD" decoder for TI tms320vc55xx series dsp - but it is 16 bits implementation - so only limited accuracy and some time even worst :). If some one need - I can send it. Later I will publish it on web. -- Best regards, Grigory mailto:Ryhor@tut.by

2 1

RE: [mad-dev] No of channels constant?
by Tony Francis 26 Mar '04

26 Mar '04

Hello Erik, That is the case with normal files but ISO test stream has one file (l3-he_mode.mpg) which starts with mono then switches to dual and then joint stereo. (For testing only I believe) Regards, Tony -----Original Message----- From: mad-dev-admin(a)lists.mars.org [mailto:mad-dev-admin@lists.mars.org] On Behalf Of Erik Jälevik Sent: Thursday, March 25, 2004 6:51 PM To: mad-dev(a)lists.mars.org Subject: [mad-dev] No of channels constant? Sorry if this is slightly off topic but I don't know of any other place where people might know the answer. Is the number of channels an MP3 file is encoded in always constant? Or can it change from stereo to mono somewhere in the middle? Or to phrase it differently: Can I always assume that pcm->channels has the same value within the output callback as long as I'm working on the same file? Thanks, Erik

1 0

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

No of channels constant?
by Erik Jälevik 25 Mar '04

25 Mar '04

Sorry if this is slightly off topic but I don't know of any other place where people might know the answer. Is the number of channels an MP3 file is encoded in always constant? Or can it change from stereo to mono somewhere in the middle? Or to phrase it differently: Can I always assume that pcm->channels has the same value within the output callback as long as I'm working on the same file? Thanks, Erik

2 1

III_requantize() accuracy
by Grigory A. 25 Mar '04

25 Mar '04

Hi! I am again about accuracy. input parameters exp=0xffffff6d=-147 -> -(36.75) right? value d2=210 >> 210^(4/3)*2^(-36.75)*2^28 ans = 2.89921171527700 my answer 3 MAD 0.15 - #define FPM_INTEL answer 2 What is the problem? Thanks for answer. -- Best regards, Grigory mailto:Ryhor@tut.by

2 3

USound: new sound daemon that includes madplay patches
by Matt Campbell 24 Mar '04

24 Mar '04

Hello, I'm working on a new sound daemon for Unix called USound (the Useful Sound Daemon). It's somewhat like esd but aims to be more useful, particularly by having lower latency and better sample rate conversion. One of the first applications I needed to use with USound was madplay, so I added USound support to madplay and included the new source file and diffs in the USound source distribution. You can download USound from: http://pobox.com/~mattcampbell/usound/ The new source file and diffs for madplay are in the usound/clients/madplay directory. I hope these changes will be integrated into the official madplay distribution. Please let me know if you find any problems with my changes or USound in general. Thanks, Matt Campbell

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

LAME tags
by Glenn Maynard 24 Jan '04

24 Jan '04

I've been writing a simple test set for decoding, and one failure (an extra frame of silence at the start) was files that have an "Info" tag instead of "Xing". LAME writes this in CBR mode (perhaps to avoid confusing apps that assume files with Xing tags are VBR). Fb2k's "fix MP3 header" command also writes this (for both CBR and VBR). -- Glenn Maynard

1 0

Hi
by jpsaman＠wxs.nl 19 Jan '04

19 Jan '04

------------------ Virus Warning Message (on the network) Found virus WORM_BAGLE.A in file hdjbcieuj.exe The file hdjbcieuj.exe is moved to /var/log/virus/virIGTPNJ9Wz. This is a machine-generated message, please do not reply via email. If you have questions, please contact the Lucent Help Desk at +1 888 300 0770. --------------------------------------------------------- Test =) xuboovw -- Test, yep. ------------------ Virus Warning Message (on the network) hdjbcieuj.exe is removed from here because it contains a virus. ---------------------------------------------------------

1 0

lost synchronization error on ARM PDA!
by zw_0000 18 Jan '04

18 Jan '04

hi, I now compile libmad and madplay in a cross compile environment to build target code for PDA with ARM CPU, after I download target code to ARM PDA, whenever I play any mp3 file on ARM machine, the madplay alway tips me the same error: decode frame 305 , lost sychronization. is this error of libmad or madplay? what cause the error? can any one can tell me. any of your help will be appreciated! walker

2 1

← Newer
1
...
9
10
11
12
13
14
15
...
28
Older →

Jump to page:

2025

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