Re: [MP3 ENCODER] new in_mpg123
Joshua I've played quite a few mp3s and it refused to play one mp3. Karsten But I have some mp3s the plugin plays half the way and then Karsten proceeds to the next song. I think it's because those files are corrupted. Most of MP3 players try to resync on erroneous frames. But mpglib seems easily break when erroneous frame is fed. So, if I simply add resync code, decoder often breaks after resync. It seems another patch for mpglib is needed. Alex Say, does anyone have a copy of the paper cited below or the ability to get Alex one? It's listed as the source for a fast MDCT algorithm used in the maplay Alex decoder. I adapted that algorithm for use in my decoder, and now I'd really Alex like to use it in an encoder as well, but I'm not familiar enough with the Alex theory to make the fairly radical changes that would require. I once posted a patch that speeds up old filter_subband, and it includes 32point IDCT code with B.G.Lee's algorithm. I also have DCT version of the code, and I'll post it if someone wants it. Monty No, but I have a later paper with a further polished algorithm that I use (with Monty my own mods; the authors were good mathemeticians, but lousy typesetters/code Monty optimizers) as the Vorbis MDCT: Monty Monty "The use of multirate filter banks for coding of high quality digital audio" Monty 6th European Signal Processing Conference, Amsterdam, June 1992, vol 1 Monty pp211-214 This paper can be downloaded from: http://www.lte.e-technik.uni-erlangen.de/~spo/eusipco.corrected.ps -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] new in_mpg123
Hi guys, K I can't tell what the problem is because it K happens only on certain songs JB I've played quite a few mp3s and it refused to JB play one mp3. Maybe you know about this little utility already, but anyways ... It was announced on one of general mp3 message boards about four months ago. Download link is on http://www.geocities.com/mp3utility/ In a word, it is a Win32 piece of software which provides one with some information on an mp3 file and has an ability to check it for consistency and such errors as missing frames etc. I always use this utility (and find it pretty helpful, actually) when I hear something strange on some particular file to see what is wrong. Hope this helps :) Greetings, -E. [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: Re[2]: [MP3 ENCODER] new in_mpg123
This could possibly help, but most of the mp3s I play are on CD already. :( -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of E. Zann Sent: Tuesday, May 02, 2000 2:51 AM To: Joshua Bahnsen Subject: Re[2]: [MP3 ENCODER] new in_mpg123 Hi guys, K I can't tell what the problem is because it K happens only on certain songs JB I've played quite a few mp3s and it refused to JB play one mp3. Maybe you know about this little utility already, but anyways ... It was announced on one of general mp3 message boards about four months ago. Download link is on http://www.geocities.com/mp3utility/ In a word, it is a Win32 piece of software which provides one with some information on an mp3 file and has an ability to check it for consistency and such errors as missing frames etc. I always use this utility (and find it pretty helpful, actually) when I hear something strange on some particular file to see what is wrong. Hope this helps :) Greetings, -E. [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] winamp quality
How about increasing the buffer size to about 4 seconds? From: Pierre Hugonnet [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [MP3 ENCODER] winamp quality Date: Tue, 02 May 2000 15:52:43 +0200 Dave Brown wrote: I've found Winamp sounds pretty bad if you enable MMX decoding. I suggest just sticking with Pentium/Pentium2 decode doesn't seem to affect cpu utilisation. It doesn't improve a lot... It seems in fact that the problem I observe is related to the process priority. Under Windows NT4, it works better (but still not perfect) if I assign a high priority to the WinAmp process. Pierre -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] A nifty winamp EQ plugin
Joshua Bahnsen wrote: If you are looking for a great EQ plugin for winamp, I suggest you look at DFX 3.0. It works GREAT! It gives it a total full sound. I can't stand to listen to mp3s anymore without this plugin. http://www.winamp.com/customize/detail.jhtml?componentId=11493 Josh Jashua, You may try the WOW Thing too: http://www.wowthing.com - Zia -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Evil GIF
Hello ha-ha-ha!!! http://www.sulaco.org/mp3/download/riaa.gif thanks Mark!!! 8) Best regards, Dmitrymail to: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Evil GIF
Hello ha-ha-ha!!! http://www.sulaco.org/mp3/download/riaa.gif thanks Mark!!! 8) original printable vector PDF file can be found at http://www.modernhumorist.com/propaganda/mp3.pdf -- Dmitry Boldyrev Subband Software, Inc. http://www.subband.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] MP3Enc upsampling /buffer
Howdy Mark, -Original Message- From: Mark Taylor [mailto:[EMAIL PROTECTED]] Sent: Monday, May 01, 2000 10:18 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [MP3 ENCODER] MP3Enc upsampling /buffer ... I should note, BTW, that the ISO 'dist10' package uses a BUFFER_SIZE of 4096 bytes... Doh. Maybe this is the buffer for a single granule, rather than the whole frame? (since part2_3_length is 4096) 'part2_3_length' is less than 4096 _bits_. 'dist10' uses a (main/ancillary data) buffer of 4096 _bytes_ - i.e. way, way too many bits! Which leads me to suggest the following: A reasonable max buffer size might be: 4096*4=16384 (or should that be 4095*4?) since this is the largest possible frame size. Not including ancillary data, of course, but that shouldn't matter unless you're trying to handle a multichannel bitstream. The buffer limitation must only be used to buffer the data from the mp3 stream? mpg123 buffers data from the current frame until it gets to the header for the second frame (or end of file) and only then does it start to decode. The buffer is just malloc()'d, with no limitations other than system memory. So mpg123 should have no problem with these types of streams. I guess I could imagine a hardware player buffering mp3 data and only allocating at most 7680 bits for the mp3 data buffer. Once this buffer is full, it decodes a frame and then fills the buffer again. But it is hard to imagine a software encoder would be written this way! Yes, the buffer limitation only really affects main (and possibly ancillary) data collection. (Which makes the number 7680 fairly arbitrary, as it is the size of an entire frame.) You always have to have a 'frame' buffer to hold the current frame data as it is decoded (unless you want to do it sequentially, as I suppose a hardware designer might). Then you need someplace to cache the main data while you build up an entire _audio_ frame's worth. Layer-III decoding is significantly more complicated than layer-I/II, due to the fact that the main data for a frame can be contained in previous frames. Thus, you basically have to buffer all the main (and usually ancillary) data you encounter while decoding until you have main_data_begin less than or equal to the amount of buffered data. If it weren't for this requirement, you could just 'buffer data from the current frame', which is what you do do with the other layers. I suppose you could buffer until you filled the buffer and then decode until you have decoded everything you can (as you described for hardware), but it makes more sense to just buffer until you know you have a full frame, so that you can pipeline things. ... Another question is the 320kbs main_data_begin. Although LAME currently enforces the 7680 bit limit, it does not actually force main_data_begin=0 for 320kbs frames as Leonid suggests. Take the following (VBR) example (numbers made up): I'd have to check to make sure, but I doubt that the ISO decoder detects nonzero main_data_begin as an error for 320 kbit/s streams. Your VBR example certainly shows why it shouldn't. The docs generally seem to predate any serious thought about VBR, though, so it seems entirely possible that ISO just hadn't thought about it at the time. Alex -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
