mad-user

mad-user@lists.mars.org

303 discussions

l3dec 24-bit convert to wav
by ff123 28 Jan '01

28 Jan '01

I have written a short program to convert the 24-bit ASCII output of l3dec to .wav format, which can be read in by Cool Edit Pro. For fun only -- I don't see a useful purpose for it. http://fastforward.iwarp.com/convert.html ff123

1 0

Re: [mad-announce] MAD 0.12.3b available
by Anthony Airon Oetzmann 24 Jan '01

24 Jan '01

On Sat, 20 Jan 2001 23:05:54 -0500, Rob Leslie wrote: >MAD version 0.12.3b is now available. > >Highlights of this release include: > > - MPEG 2.5 support Way to go. > - better mono/stereo/left/right channel selection > - attenuation option Yeah, how'd you implement those levels of sensitivity ? Any limiter code in there ? Take care and keep it up Tony

1 0

Binary of Madplay
by engdev 24 Jan '01

24 Jan '01

Do any of you nice fellows out there have a binary of Madplay that runs on windows (or ms dos) operating systems. I've looked extensively but have only managed to find source code, and, I think it was a Linux binary. I know, doze is really bad, but it has to work with other programs written for doze. I don't have the programming skills to compile my own. Thanks, Owen.

1 0

Playlist track time abnormalities
by David Shin 28 Dec '00

28 Dec '00

This has been reported before, but I just thought I'd bring it up again. When you have Winamp set to Read Titles on Play (Winamp Preferences->Options), MAD will not show the track time for the first file that's played. Not the first track on the playlist, but the first track that you try to play (which doesn't have a track time listed already). Also, VBR track time handling needs to be better (until VBR headers is supported). I realize MAD can't help reading wrong track times when Fast Playing Time Calculation is enabled, but it should show the correct times when the files are actually playing. Every other decoder changes the track time correctly (even after MAD has loaded the wrong track time into the playlist), but MAD will not. For example, if you enable MAD and load a bunch of VBR files, the wrong track times will show in the playlist. Now disable MAD, enable the default decoder, and play each of the files. The correct track times will now show. Why can't MAD do the same thing? It should send the correct track time when the file is actually playing. Even if it takes up to 5 or 6 seconds, it should still send the correct time. Is this somehow related to the previous bug where it won't show any track time at all when you first play a file in Read Titles on Play mode?

1 0

Re: [mad-user] re wishlist
by kaiwei 21 Dec '00

21 Dec '00

(2) the DSP plug-in can be used with other input sources, not just MPEG audio Just for the above reason alone, I think we should go for the 2nd method;-) Imagine, CD audio playback at 24bit!

3 2

New to the list
by Darryl Miyaguchi 20 Dec '00

20 Dec '00

Hi all, I just joined the list, and am interested in finding out if there is an archive of messages I can browse through. I'm intrigued by the idea behind MAD, and have been trying to compile a list of tests which can definitively (in the form of multiple blind listening trials) show that the differences between MAD and plain-vanilla ISO-compliant layer 3 decoders are audible. This is my web page: http://fastforward.iwarp.com/mad.html ff123 (aka Darryl Miyaguchi)

1 0

Re: [mad-user] re wishlist
by Rob Leslie 19 Dec '00

19 Dec '00

"Anthony Airon Oetzmann" <airon(a)gmx.net> wrote: > Sounds complicated to me :). I didn't figure the Winamp specs were that lax. The API is actually somewhat reasonable, it's just that not all plug-ins may support all sample sizes. > There's supposed to be a v3 of Winamp soon. I wonder how well MAD will fit > in there, given that it's supposed to be that much mroe flexible. One > distinct advantage of a single plugin-doing-it-all approach, might be the > portability to XMMS and so on. I'm not shure how compatible a seperate DSP > module will be, when realy you're using the same amount of memory and > processing time. On the contrary, portability is usually increased when you limit the number of dependencies. The DSP stuff can always be folded back in if there is not an equivalent place to put it in a port to another platform. > Is it possible to control a DSP plugin from inside an input plugin ? That's > what I'd gathered from your idea of the "High-resolution DSP support" switch > that's greyed right now. It's possible to control the DSP plug-ins so far as to decide whether to invoke them at all, what sample size to feed them, and of course the samples themselves. > Remember that the DSP will rake in the dithering code, since all else would > destroy the profit made from having 24 or 32 bit output in the first > place. It's not great to dither audio twice either if you're going 16 bit > out and DSP'ing it to 16 bit again after processing it perhaps in 24 or 32 > bit with the DSP plugin. Eh? I'm not suggesting to dither twice. Here's the current picture for 16-bit output: +-----+ +-----+ +----------------+/ | MAD | --32--> dither --16--> | DSP | --16--> | Output Plug-in |- audio +-----+ +-----+ +----------------+\ Here's what I'm proposing with the high-res DSP option: +-----+ +-----+ +----------------+/ | MAD | --32--> | DSP | --32--> dither --16--> | Output Plug-in |- audio +-----+ +-----+ +----------------+\ In all cases "--32-->" means MAD's internal 24-bit + 3-bit headroom sample representation. > I'm not shure a modular design has that many advantages, but to provide two > seperate setting controls. While I think this is indeed probably an advantage, the other advantages are (1) I can eventually call the MAD input plug-in "finished" and concentrate on the DSP stuff independently, (2) the DSP plug-in can be used with other input sources, not just MPEG audio, (3) maybe others would be interested in contributing to the DSP plug-in, being less complex than a full-blown decoder, (4) a bug in one plug-in can be isolated from the other, (5) etc. Cheers, -rob

2 1

re wishlist
by Anthony Airon Oetzmann 19 Dec '00

19 Dec '00

On Mon, 18 Dec 2000 21:26:03 -0500, Rob Leslie wrote: >If I write the DSP plug-in myself, I can support 24-bit samples with 3-bit >headroom without any problem. >Actually many DSP plug-ins can probably handle 24- or 32-bit samples, so this >probably isn't a big issue. >What's needed is a way to send high-resolution samples to the DSP plug-ins and >then dither to 16 bits (or whatever resolution) afterwards. That's what I plan >the "High-resolution DSP support" configuration option to be for. Sounds complicated to me :). I didn't figure the Winamp specs were that lax. There's supposed to be a v3 of Winamp soon. I wonder how well MAD will fit in there, given that it's supposed to be that much mroe flexible. One distinct advantage of a single plugin-doing-it-all approach, might be the portability to XMMS and so on. I'm not shure how compatible a seperate DSP module will be, when realy you're using the same amount of memory and processing time. Is it possible to control a DSP plugin from inside an input plugin ? That's what I'd gathered from your idea of the "High-resolution DSP support" switch that's greyed right now. Remember that the DSP will rake in the dithering code, since all else would destroy the profit made from having 24 or 32 bit output in the first place. It's not great to dither audio twice either if you're going 16 bit out and DSP'ing it to 16 bit again after processing it perhaps in 24 or 32 bit with the DSP plugin. I'm not shure a modular design has that many advantages, but to provide two seperate setting controls. Tony

1 0

Re: [mad-user] wishlist
by Rob Leslie 19 Dec '00

19 Dec '00

"Anthony Airon Oetzmann" <airon(a)gmx.net> wrote: >> I wonder though if it wouldn't be better to implement this in a special DSP >> plug-in rather than further complicate the input plug-in... > > When would Winamp ever support 24 bit output of an input plugin? Trouble is, > you'll degrade the output if the plugin is used on 16 bit output up > front. Use it on 24 bit output however, and then dither that and you'll keep > your high resolution that was the point of MAD in the first place. If I write the DSP plug-in myself, I can support 24-bit samples with 3-bit headroom without any problem. Actually many DSP plug-ins can probably handle 24- or 32-bit samples, so this probably isn't a big issue. What's needed is a way to send high-resolution samples to the DSP plug-ins and then dither to 16 bits (or whatever resolution) afterwards. That's what I plan the "High-resolution DSP support" configuration option to be for. Cheers, -rob

1 0

Re: [mad-user] wishlist
by Rob Leslie 19 Dec '00

19 Dec '00

"Anthony Airon Oetzmann" <airon(a)gmx.net> wrote: >>> I am considering an option to set a permanent attenuation setting when >>> auto attenuation is disabled. >> >> Unless your entire MP3 collection has the same dynamic characteristics, >> I don't see how this would be very useful. > > I'd favor a manualy settable attenuation for each song either way. I think I will eventually implement: - manually settable global (default) attenuation - manually settable and remembered per-file attenuation When auto attenuation is enabled, the global/default attenuation is 0 dB but per-file attenuation will be whatever level the auto attenuation ends at. > Btw Rob, how's that code ? Workable ? (Tony sent me some code that implements a compressor.) Yes, it's enough to understand how to do it; thanks. I wonder though if it wouldn't be better to implement this in a special DSP plug-in rather than further complicate the input plug-in... Cheers, -rob

2 1

← Newer
1
...
24
25
26
27
28
29
30
31
Older →

Jump to page:

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-user