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@mp3-tech.org mobile phone: gsm@mp3-tech.org icq: 12138873
MP3' Tech: www.mp3-tech.org personal page: gabriel.mp3-tech.org
"Gabriel Bouvigne" bouvigne@mp3-tech.org wished for:
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
Would it be enough to remember the attenuation setting after the song has been completely decoded, and reuse it when the song is played again?
I am considering an option to set a permanent attenuation setting when auto attenuation is disabled.
I haven't decided yet whether I want to implement a full-blown compressor.
Decoding: Ability to enable/disable dithering
I could do this. There may in fact eventually be a choice of dithering algorithms.
Decoding: mpeg 2.5
This is coming, but I need to find a definitive specification first. Do you know where to find one?
Information: information about the encoder used to produce the file
If not in an ID3v2 tag frame, where is this to come from? ID3v2 support is still on the list.
Vbr header: use and do not decode it.
Yes, this is Nawhead's wish too. :-)
Visual information: Ability display M/D/S/MS/IS/IMS in the winamp area used to display the bitrate
Unfortunately I don't think this is possible, unless you don't mind viewing the information as a number. This probably won't happen.
Plugin info: reseting the info box on file change
I'm not sure what you mean?
Decoding quality: an even better decoding quality due to post processing (oversampling)
A few people have mentioned oversampling to me, but I'm not yet convinced of the benefit.
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.
It may be possible to improve this.
CPU usage: use only 0.00005% of the cpu
If you'd like to help hack on performance, the source code is available... please jump in. :-)
mpeg 2: decoding of multichannel files (ok, we'll have to made an encoder first)
I'm torn over whether to implement this now or do AAC first.
I'll stop here, otherwise it seems that I could give you work for the full next year.
Thanks for the consideration. ;-)
Cheers, -rob
Is oversampling the same as upsampling? if not, any technical papers I can read on it?
kaiwei
Long ago, in a far away galaxy on 00:13 12/18/2000, Rob Leslie said
Decoding quality: an even better decoding quality due to post processing (oversampling)
A few people have mentioned oversampling to me, but I'm not yet convinced of the benefit.
On Mon, 18 Dec 2000 00:34:33 +0800, kaiwei wrote:
Is oversampling the same as upsampling? if not, any technical papers I can read on it?
You could say that. With oversampling for example, the Hardware TC 2240 Delay Unit handles audio with 1MHz sample frequency. I'm not shure about the details however.
Oversampling is a pretty moot point if it works this way. Most cards can't go beyond 44.1/48 kHz sample frequency playback, and you need multiples of that. I dunno. Maybe the DAC's in some chips aleady do that to the output anyway. The audio shure would sound horrible without it.
Tony
Rob Leslie 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 haven't decided yet whether I want to implement a full-blown compressor.
Information: information about the encoder used to produce the file
If not in an ID3v2 tag frame, where is this to come from? ID3v2 support is still on the list.
I'm pretty sure there's no way to find out what encoder was used. There's certainly no tag field or common characteristic to look for.
Vbr header: use and do not decode it.
Yes, this is Nawhead's wish too. :-)
:-D
Plugin info: reseting the info box on file change
I'm not sure what you mean?
I think he means, if you're looking at an info box, and the song changes, the info box would automatically change to the next song's information. I don't like this idea, or my understanding of this idea anyway.
I am considering an option to set a permanent attenuation setting when
auto
attenuation is disabled.
It would be fine for me.
Decoding: mpeg 2.5
This is coming, but I need to find a definitive specification first. Do
you
know where to find one?
Everything seems to be like mpeg2, but as it's not an official standard, there is no real doc about it, sorry.
Information: information about the encoder used to produce the file
If not in an ID3v2 tag frame, where is this to come from? ID3v2 support is still on the list.
I think a very complicated scheme based on encoding particularities could be done, but as I said, very complicated. For Blade, if you've got a file where all crcs are broken, it's 99.999% sure that it comes from Blade. For Lame, it's written in the VBR header and also in the ancillary data. Delay and character used for padding could also be an indication.
Visual information: Ability display M/D/S/MS/IS/IMS in the winamp area used to display the bitrate
Unfortunately I don't think this is possible, unless you don't mind
viewing
the information as a number. This probably won't happen.
I didn't know you are only able to use numbers in this box.
Plugin info: reseting the info box on file change
I'm not sure what you mean?
Resetting the info like number of decoded samples, clipping level, MS usage when the track change.
Decoding quality: an even better decoding quality due to post processing (oversampling)
A few people have mentioned oversampling to me, but I'm not yet convinced
of
the benefit.
I'm starting to asking myself if a separate library for sound processing wouldn't be a good thing. Dithering and oversampling could be put in this one.
Regards,
--
Gabriel Bouvigne - France bouvigne@mp3-tech.org mobile phone: gsm@mp3-tech.org icq: 12138873
MP3' Tech: www.mp3-tech.org personal page: gabriel.mp3-tech.org
"Gabriel Bouvigne" bouvigne@mp3-tech.org wished for:
Information: information about the encoder used to produce the file
If not in an ID3v2 tag frame, where is this to come from? ID3v2 support is still on the list.
I think a very complicated scheme based on encoding particularities could be done, but as I said, very complicated. For Blade, if you've got a file where all crcs are broken, it's 99.999% sure that it comes from Blade. For Lame, it's written in the VBR header and also in the ancillary data. Delay and character used for padding could also be an indication.
I think it's dangerous to make assumptions about the encoder based on characteristics of the bitstream; what's true today may not be true tomorrow.
It would be much better to read this information from e.g. an ID3v2 tag.
Plugin info: reseting the info box on file change
I'm not sure what you mean?
Resetting the info like number of decoded samples, clipping level, MS usage when the track change.
I see. Unfortunately I don't like this idea because the Statistics tab makes up part of the properties for a single file. That's why the updates stop once the file has stopped playing. I think what you really want is a separate window that is independent of any file and always displays this information.
I'm not sure what interface in Winamp could be used to show this.
Decoding quality: an even better decoding quality due to post processing (oversampling)
A few people have mentioned oversampling to me, but I'm not yet convinced of the benefit.
I'm starting to asking myself if a separate library for sound processing wouldn't be a good thing. Dithering and oversampling could be put in this one.
A DSP plug-in with explicit support for MAD's internal sample format?
-rob
I think a very complicated scheme based on encoding particularities
could be
done, but as I said, very complicated. For Blade, if you've got a file where all crcs are broken, it's 99.999%
sure
that it comes from Blade. For Lame, it's written in the VBR header and also in the ancillary data. Delay and character used for padding could also be an indication.
I think it's dangerous to make assumptions about the encoder based on characteristics of the bitstream; what's true today may not be true
tomorrow.
It would be much better to read this information from e.g. an ID3v2 tag.
Ok, I understand your point. But at least for Lame, it's easy and it's "safe". If you don't want to read the ancillary data, at least you could use the VBR header. If you program VBR header parsing, knowing if the file was produced by Lame is trivial.
One last thing: would it be possible to change this mailing list behaviour so that when we reply to a mail, the default adress would be the ML instead of the previous sender?
Regards,
--
Gabriel Bouvigne - France bouvigne@mp3-tech.org mobile phone: gsm@mp3-tech.org icq: 12138873
MP3' Tech: www.mp3-tech.org personal page: gabriel.mp3-tech.org
"Gabriel Bouvigne" bouvigne@mp3-tech.org wrote:
One last thing: would it be possible to change this mailing list behaviour so that when we reply to a mail, the default adress would be the ML instead of the previous sender?
Here's why I think this is a bad idea:
http://www.unicom.com/pw/reply-to-harmful.html
The only reasonable objection I know to the current behavior is that reply-to-all may include both the address of the author and the list, so the author (being subscribed to the list) receives a duplicate. However, I have come to think this is still better than munging the Reply-To header and it is easier to remove the author's address from outgoing messages out of courtesy than it is to add it in case you really want to send a message to the author and not the whole list.
Cheers, -rob
On Mon, 18 Dec 2000 07:33:08 -0500, David Shin wrote:
Rob Leslie 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. Is someone here that can program a little mass-idv2-attenuation-setting tool ? For example, the Eminem album is mastered to be very loud. The old Mama Said Knock You Out/LL Cool J is not. I don't wanna tur a volume knob if I'm listening to material from these two albums, being a lazy person in that respect. I also don't want to screw up the material with a limiter or compressor. This differs from just protecting output against little peak jumps, for which I think a limiter would be a fine tool.
So a manual setting for a song would be handy, as soon as it works of course.
Btw Rob, how's that code ? Workable ?
Tony
-
Anthony Airon Oetzmann -
David Shin -
Gabriel Bouvigne -
kaiwei -
Rob Leslie