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: [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: [MP3 ENCODER] MP3Enc upsampling /buffer
> > > 2. I use 1440+512 bytes (11520 + 4096 bits) buffer in decoder. > >If any bitstream uses frame buffer > 7680 bits - not a problem. > > I do a similar, but less smart, thing in my decoder. I use 7680 + 4096 bits > for the buffer, where 7680 is the 'maximum' frame size (though I only ever > buffer main/ancillary data) and 4096 is the max main_data_begin. I think I > may switch it to yours above. In any case, in software it's just a #define, > and most machines have RAM to burn these days... > > >I'm sure every decoder should decode (and play music) > >rather then locate incompliances in bitstream. 1 KB is not a cost. > > Amen. > > My decoder has the buffer limitations above. Since we basically always run > at 64 kbit stereo, I could probably make my buffer much smaller, but I'm > trying to be a compatible as I can for now. If I ran into a bitstream that > crashed my decoder for buffer reasons, I'd definitely just up the size. > > 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) 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. 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! Also, the MPEG2 spec allows for much larger frame sizes because for the 5.1 channel encoding, the 3,4 and 5 channels are encoded in the ancillary data. layer III, 44.1khz multichannel audio allows for frame sizes up to 947kbs. (which leads to another possible non-standard extension that well written player should handel: free format, fixed bitrates up to 947kbs!) 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): bits added max_bits bits usedmain_data_beginto reservior Frame 0: 128kbs 32003100 0100 Frame 1: 128kbs 32002900 100 300 Frame 2: 320kbs 82007680 400 520 Frame 3: 128kbs 32003900 920 -700 If frame 2 requires main_data_begin = 0, it would force us to waste 400 bits (by adding 400 bits into the ancillary data of frame 1). Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME Windows ACM
> > There has been a number of requests for an ACM. Acy Stapp had a go but had > problems with the Windows ACM not supporting VBR, but the main problem was > LAME was not thread safe at the time which the ACM requires. I see Mark T > has made some changes in his area so maybe its time for another try. > > Ross. > The thread safe work is mostly done - but I tried encoding two things simultaneously last week and it failed miserably :-(. I just found some more static, non-constant variables in newmdct.c, and there are probably a few more static variables floating around that need to be moved into the "gfc" struct. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] LAME Windows ACM
There has been a number of requests for an ACM. Acy Stapp had a go but had problems with the Windows ACM not supporting VBR, but the main problem was LAME was not thread safe at the time which the ACM requires. I see Mark T has made some changes in his area so maybe its time for another try. Ross. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Zia Mazhar > Sent: Monday, 1 May 2000 23:31 > To: [EMAIL PROTECTED] > Subject: [MP3 ENCODER] MP3 Encoding Plugin > > > Found it at last: > > http://ftp.winamp.com/components/P/out_mp3.exe > > Yes, it requires an ACM Codec installed. Is there any > probabillity that LAME will release one? :-) > > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] new in_mpg123
I've been using this since you posted this message, I've played quite a few mp3s and it refused to play one mp3. I was playing a playlist for an album and it just skipped right over it. So I tried to just open that one file and it doesn't play it. I know it was encoded with the Radium enhanced codec, the rest of the album was also encoded with the same encoder, plays fine. Other than that, it plays nicely, very low CPU usage (as to be expected from mpg123). Josh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Naoki Shibata Sent: Monday, May 01, 2000 5:02 AM To: [EMAIL PROTECTED] Subject: [MP3 ENCODER] new in_mpg123 I released new version of in_mpg123. New features implemented are: 1. ID3 title formatting 2. option to suppress zero samples at the beginning of file 3. seekbar I have not tested it heavily. Bug reports are welcome. http://www.geocities.co.jp/Technopolis/9674/in_mpg123.html -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MDCT paper request
> I'd be happy to provide the results to LAME once I get it working...
>
> @Article{Lee_ANew_ASSP84,
> journal = "{IEEE} Trans. Acoustics, Speech and Signal
> Processing",
> author = "B. G. Lee",
> title ="A New Algorithm to Compute the Discrete Cosine
> Transform",
> year = "1984",
> volume = "{ASSP-32}",
> number = "6",
> pages ="1243",
> }
No, but I have a later paper with a further polished algorithm that I use (with
my own mods; the authors were good mathemeticians, but lousy typesetters/code
optimizers) as the Vorbis MDCT:
"The use of multirate filter banks for coding of high quality digital audio"
6th European Signal Processing Conference, Amsterdam, June 1992, vol 1
pp211-214
(Not sure why they chose that title. It's 95% on a specific MDCT algorithm
description).
Interested?
Monty
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] MDCT paper request
Howdy All,
Say, does anyone have a copy of the paper cited below or the ability to get
one? It's listed as the source for a fast MDCT algorithm used in the maplay
decoder. I adapted that algorithm for use in my decoder, and now I'd really
like to use it in an encoder as well, but I'm not familiar enough with the
theory to make the fairly radical changes that would require.
I'd be happy to provide the results to LAME once I get it working...
@Article{Lee_ANew_ASSP84,
journal = "{IEEE} Trans. Acoustics, Speech and Signal
Processing",
author = "B. G. Lee",
title ="A New Algorithm to Compute the Discrete Cosine
Transform",
year = "1984",
volume = "{ASSP-32}",
number = "6",
pages ="1243",
}
Thanks,
Alex
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] MP3Enc upsampling /buffer
Howdy, > -Original Message- > From: Leonid A. Kulakov [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 28, 2000 3:33 AM > To: [EMAIL PROTECTED] > Subject: Re: [MP3 ENCODER] MP3Enc upsampling /buffer > > I've got some points on this issue. > > 1. ISO docs has a number of errors and typos, this can be one of them. >May be authors wanted to set buffer restriction to maximum, but >forgot that maximum frame size corresponds to maximal bitrate >and MINIMAL samplerate and took both maxima for computation? >p. 2.4.3.4.4 in ISO 11172-3 is not apparent enough to be the truth. It is pretty clearly wrong to use max bitrate and max samplerate when min samplerate produces a larger value. I'm not sure what ISO mean by the final sentence of the section under consideration, "At sampling frequencies lower than 48 kHz the buffer should be constrained such that the same physical buffer size is sufficient as the one calculated for the for the 48 kHz case above." The sentence seems to contradict itself (and is not grammatically correct in any case - does anyone have a non-English version of the spec which makes more sense?) - how can the buffer be constrained in a variable way to the same size? Is it possible to interpret this clause to mean that the buffer size should be adjusted up for lower samplerates? > 2. I use 1440+512 bytes (11520 + 4096 bits) buffer in decoder. >If any bitstream uses frame buffer > 7680 bits - not a problem. I do a similar, but less smart, thing in my decoder. I use 7680 + 4096 bits for the buffer, where 7680 is the 'maximum' frame size (though I only ever buffer main/ancillary data) and 4096 is the max main_data_begin. I think I may switch it to yours above. In any case, in software it's just a #define, and most machines have RAM to burn these days... >I'm sure every decoder should decode (and play music) >rather then locate incompliances in bitstream. 1 KB is not a cost. Amen. ... > > Maybe Alex Broadhead could comment on if the decoder he just > > wrote could handle this? Sorry, I was off for a few days there. My decoder has the buffer limitations above. Since we basically always run at 64 kbit stereo, I could probably make my buffer much smaller, but I'm trying to be a compatible as I can for now. If I ran into a bitstream that crashed my decoder for buffer reasons, I'd definitely just up the size. I should note, BTW, that the ISO 'dist10' package uses a BUFFER_SIZE of 4096 bytes... Doh. Alex -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] A nifty winamp EQ plugin
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 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] more on the winamp decoder bug
> > > > Ross> Has anyone bothered telling Nullsoft about this bug? > > > > This has been already fixed in winamp 2.61. > > > > > > -- > > Naoki Shibata e-mail: [EMAIL PROTECTED] > > On the web page, I said I was using 2.4, but that was a typo, > I was using 2.6. > > I'm downloading 2.62 right now, I'll see how it does. > > Mark > just tried Winamp 2.62: Same problems. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] more on the winamp decoder bug
> > Ross> Has anyone bothered telling Nullsoft about this bug? > > This has been already fixed in winamp 2.61. > > > -- > Naoki Shibata e-mail: [EMAIL PROTECTED] On the web page, I said I was using 2.4, but that was a typo, I was using 2.6. I'm downloading 2.62 right now, I'll see how it does. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CD reader for Winamp
Interesting poster by RIAA? ;) http://www.modernhumorist.com/propaganda/ sorry for spam, just thought it was really funny. -- Dmitry Boldyrev Subband Software, Inc. http://www.subband.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] new in_mpg123
Hiho, Naoki Shibata <[EMAIL PROTECTED]> ! On Mon, 01 May 2000 18:01:31 +0900 you wrote: > I released new version of in_mpg123. > I have not tested it heavily. Bug reports are welcome. Absolutly nice. But I have some mp3s the plugin plays half the way and then proceeds to the next song. I can't tell what the problem is because it happens only on certain songs (songs which I haven't encoded for myself - so I don't know the encoder / settings used) Karsten -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CD reader for Winamp
> Thanx, I'll try it out some time I'm out of town at the moment. The only thing I >have to lose is disk space & a lot of bad MP3ing habits... :-D So which EQ does it >use? And how does it compare to, for example, standalone CD rippers such as CDex, EAC? Thank Naoki! Yes, it is sure worth of trying... I have that MP3ing habit too, and can't call it really good since it wastes a lot of time... It uses the EQ of WinAmp. Well, I have played/ripped some tracks with it and they sounded just fine. My CDs were very new and didn't have any scratches. The main feature it may lack is the capability of jitter correction. That is a must have function of a ripper. Reading the readme file it seems that it does perform the correction, but it's not been stated clearly enough. I shall try it with my "reference" scratchy CD to test it! - Zia -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] CD reader for Winamp
Thanx, I'll try it out some time I'm out of town at the moment. The only thing I have to lose is disk space & a lot of bad MP3ing habits... :-D So which EQ does it use? And how does it compare to, for example, standalone CD rippers such as CDex, EAC? Shawn At 05:17 PM 5/1/00 +0600, Zia wrote: >This plugin extracts DA from the CD-ROM and then equalizes it while playing. >So, you can sure hear how it sounds *before* you decide to capture it in a wave file >using the disc writer plugin... -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME encoder plugin for WinAmp?
Zia> Sorry for my repetition. But I was unable to find that plugin on Winamp.com. Zia> Either they have removed it or I didn't see it... Could you please send me the Zia> location from where I can download it? Thanks. It's here. http://www.winamp.com/customize/detail.jhtml?componentId=177 -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] MP3 Encoding Plugin
Found it at last: http://ftp.winamp.com/components/P/out_mp3.exe Yes, it requires an ACM Codec installed. Is there any probabillity that LAME will release one? :-) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME encoder plugin for WinAmp?
> As I mentioned there is a plugin but it uses the FHG ACM which you need to > install first. It should be in the Plugins section on Winamp.com. > > Ross. > Sorry for my repetition. But I was unable to find that plugin on Winamp.com. Either they have removed it or I didn't see it... Could you please send me the location from where I can download it? Thanks. - Zia -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] EQing w/LAME encoder plugin for WinAmp?
By the way, Shawn, this isn't the LAME Encoder plugin for WinAmp. This is the CDDA reader plugin... You'll have to encode the wave files after you get them with the disc writer plugin. Hope you like it! - Zia -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] EQing w/LAME encoder plugin for WinAmp?
> Hey, excellent. Does it resample as well? If so, what sort of job does it do? Not >that it matters... Lame does that anyway. The trouble with EQing to taste is that you >need excellent pitch recognition & a lot of guesswork to make it worthwhile if you >can't actually hear what the EQing is going to be like. This plugin extracts DA from the CD-ROM and then equalizes it while playing. So, you can sure hear how it sounds *before* you decide to capture it in a wave file using the disc writer plugin... I just tried it - works like a charm! Go to the author's homepage for the latest version, which is: http://www.url.ru/~copah/CDReader.htm - Zia -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] more on the winamp decoder bug
>Ross> Has anyone bothered telling Nullsoft about this bug? > > This has been already fixed in winamp 2.61. Sorry, it's not fixed yet. Some kind of bug is fixed in 2.61, so I confused. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] more on the winamp decoder bug
Ross> Has anyone bothered telling Nullsoft about this bug? This has been already fixed in winamp 2.61. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] more on the winamp decoder bug
Has anyone bothered telling Nullsoft about this bug? Ross. Mark Taylor wrote: > I put a web page together on the winamp decoder bug, since I've > now recieved 4 independent LAME bug reports related to these > pure sine wave and "sweep" test cases. > > www.sulaco.org/mp3/winamp/winamp.html > > This shows plots of the winamp and mpg123 decoded wav files, > showing two errors in winamp when decoding a pure 100Hz sine > wave: periodic dropout (it looks like 1 granule, about every 1 second > is replaced by zeros) and some glitches at the very beginning of the > decoded file. > > I also added links to Naoki's page and Matt's results. > > Mark > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] new in_mpg123
I released new version of in_mpg123. New features implemented are: 1. ID3 title formatting 2. option to suppress zero samples at the beginning of file 3. seekbar I have not tested it heavily. Bug reports are welcome. http://www.geocities.co.jp/Technopolis/9674/in_mpg123.html -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] EQing w/LAME encoder plugin for WinAmp?
Hey, excellent. Does it resample as well? If so, what sort of job does it do? Not that it matters... Lame does that anyway. The trouble with EQing to taste is that you need excellent pitch recognition & a lot of guesswork to make it worthwhile if you can't actually hear what the EQing is going to be like. Shawn At 06:46 PM 4/30/00 +0600, Zia wrote: >Thanks to Naoki for unearthing this plugin. Would come handy. Shawn, with >this you can now digitally "eq to taste" your files prior to encoding. ;-) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
