mad-user December 2000

mad-user@lists.mars.org

12 participants
35 discussions

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

Winamp plug-in pre-release 0.12.3b-pre4
by Rob Leslie 18 Dec '00

18 Dec '00

The fourth pre-release: http://www.mars.org/home/rob/proj/mpeg/mad-plugin/in_mad-0.12.3b-pre4.zip Not much has changed for auto attenuation, but this version does have a few extra bonuses: - output channel selection now works (that's for you, Roj) - by request, the title format can now include conditionals What are title conditionals? If you want the title to include the ID3 Title if present but the filename otherwise, you can now enter: %?2<%2|%7> These can nest, so something more complicated might be: %?1<%1%?3< (%?4<%4/>%3)>: >%?0<%0. >%?2<%2|%7>%?6< [%6]> This results in titles like: Filename Title Artist: Filename Artist: Title Artist (Album): Title Artist (Year/Album): Title Artist (Year/Album): 01. Title Artist (Year/Album): 01. Title [Genre] ...all depending on which ID3 tag values are present in the file. The default title is now: %?1<%1 - >%?2<%2|%7> Cheers, -rob

2 3

wishlist
by Gabriel Bouvigne 18 Dec '00

18 Dec '00

You already made my 2 first wishes before I had to ask (priority setting and ability to disable the plugin). My other wishes are (no particular order): Output: Ability to set a permanent attenuation level. This attenuation would be done first, then the auto attenuation would be done after. This would allow to reduce clipping without the level changes caused by auto attenuation Decoding: Ability to enable/disable dithering Decoding: mpeg 2.5 Information: information about the encoder used to produce the file Vbr header: use and do not decode it. Visual information: Ability display M/D/S/MS/IS/IMS in the winamp area used to display the bitrate Plugin info: reseting the info box on file change Decoding quality: an even better decoding quality due to post processing (oversampling) Error correction: ability to correct the kind of errors present in the file I sent you, and use interpolation when a frame can't be decoded. CPU usage: use only 0.00005% of the cpu mpeg 2: decoding of multichannel files (ok, we'll have to made an encoder first) I'll stop here, otherwise it seems that I could give you work for the full next year. Regards, -- Gabriel Bouvigne - France bouvigne(a)mp3-tech.org mobile phone: gsm(a)mp3-tech.org icq: 12138873 MP3' Tech: www.mp3-tech.org personal page: gabriel.mp3-tech.org

5 9

Re: [mad-user] Re: Winamp plug-in pre-release 0.12.3b-pre3
by David Shin 18 Dec '00

18 Dec '00

LAME VBR Roger Ramsey wrote: > > I'm catching up on my reading and by question to you is: > > Why on God's Green Earth would you want absolutely **ANYTHING** to do with > that retroactive abortion known as Xing **ESPECIALLY** in that pure > excrement known as its VBR mode? > > Just asking... > > Roj > > ----- Original Message ----- > From: "David Shin" <naw(a)SoftHome.net> > To: "MAD User Mailing List" <mad-user(a)lists.mars.org> > Sent: Friday, December 15, 2000 6:27 AM > Subject: Re: [mad-user] Re: Winamp plug-in pre-release 0.12.3b-pre3 > > > Rob Leslie wrote: > > > > > > David Shin <naw(a)SoftHome.net> wrote: > > > > I have a question though, how does the gradual attenuation work? > > > > > > I thought I explained it succinctly, but I'll try again. :-) > > > > > > Whenever clipping occurs, the peak clipped value is examined and a new > > > attenuation setting is calculated. Previously (or with the "Most" > sensitivity > > > setting) the new attenuation is one that would have avoided the clipping > > > entirely. This can cause sharp drops in the output signal level that may > not > > > be desirable, especially if it was only a few clipped samples. > > > > > > With a less sensitive setting, the new attenuation is somewhere between > the > > > previous setting and one that would avoid the clipping entirely. This > way, if > > > clipping continues, the attenuation will gradually still be increased to > the > > > point that clipping no longer occurs. > > > > > > Once increased, the attenuation is never decreased unless the "Reset" > button > > > is pressed in the Statistics tab. > > > > Ah, that clarified it. I just wanted to know where that "between" point > > was for settings less than Most. This question sort of went along with > > my "do you need all those gradations?" I think a Most and then a Least > > and Moderate setting is all you'd really need. But I think 8 gradations > > is overkill, and doesn't offer any real benefit. Yet I think a > > coninuously changing attenuation would be even better. It doesn't even > > need to look ahead, like the limiter that Anthony is talking about. > > > > > > Is all this pre-releasing building up to a Christmas day present for > all > > > > the devoted good little MAD users out there? If so, reading Xing VBR > > > > headers is on top of my Santa list! > > > > > > Santa is making a list and checking it twice. ;-) > > > > I'll be sure to leave out my virtual milk and cookies! > > > > ---------- > > | | <------Oreo > > ----------

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