[MP3 ENCODER] Soft time-domain filtering

According to its documentation, FhG uses "soft time-domain filtering" (whatever that is) in higher quality modes. Has anyone experimented with this for LAME? Does it partly explain the large coding delay in FhG? -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] encoding with 24k / downsampling by2 patch

hi. i am new to this list. i use lame for a while now as the encoder for an icecast at a local club. ( http://vienna.mp3.at:8000/flex or directly on http://flxmp3.flex.at:8000 ). (this weekend i will set the stream to 40 or 48kbit since a radio (a real readio) station at the other and of

Re: [MP3 ENCODER] encoding with 24k / downsampling by2 patch

i thought that the chirp could evntually be an aliasing effect where frequencis in the range above 11khz are mirroed into lower bands by the sampling process. in order to rule that out i did some testing with encoding a short wav file.. i implemented a downsample by 2 quick hack into the

[MP3 ENCODER] quantization formula

Okay, here it is, the quant formula I promised some time ago: We got a sample x, floating point, positive (put the sign back on later, if you like). Calculate i = floor(pow(x, 0.75)) as usual. i is integer. Now: if (x pow(0.5 * (pow(i, 8.0/3.0) + pow(i+1, 8.0/3.0)) , 0.375)) i++;

Re: [MP3 ENCODER] encoding with 24k / downsampling by2 patch

One thing to try is to check the latest CVS version of LiveIce - the sample rate conversion code has changed a lot from the version of Icecast which is on icecast.org - specifically it removed a number of high end frequency artifacts. i was under the impression that liveice only calls the

Re: [MP3 ENCODER] twinvq

It is proprietary and the details have not been published. However, there are several technical publications from early in TwinVQ development (I have them) describing the basis of TwinVQ and there's TwinVQ reference code in the MPEG-4 reference distribution. According to the paper

[MP3 ENCODER] short blocks patch

Here is a little modification over the block switching to prevent switching in the case where the big surge is from the first subblock to the next ones. In this case, long block will only lead to a post echo of less than 20ms, wich won't be heard. Regards, Gabriel Bouvigne - France [EMAIL

Re: [MP3 ENCODER] twinvq

According to the paper available(quite interesting), it seems that VQF is the 2nd release of TwinVQ. Possible. I lost direct touch with its development in '96. note: vector quantization, in picture or music, is good for low bitrates, as it produces some good results. However, using only

Re: [MP3 ENCODER] quantization formula

Okay, here it is, the quant formula I promised some time ago: We got a sample x, floating point, positive (put the sign back on later, if you like). Calculate i = floor(pow(x, 0.75)) as usual. i is integer. Now: if (x pow(0.5 * (pow(i, 8.0/3.0) + pow(i+1, 8.0/3.0)) , 0.375))

Re: [MP3 ENCODER] BladeEnc vs. LAME at high bitrates

X-Authentication-Warning: cs.csoft.net: $s=geek.rcc.se doesn't match $[EMAIL PROTECTED] X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f Date: Fri, 26 Nov 1999 01:17:43 -0500 (EST) From: [EMAIL PROTECTED] (Ambrose Feinstein) Sender: [EMAIL PROTECTED]

Re: [MP3 ENCODER] BladeEnc vs. LAME at high bitrates

"S" == Sergey A Maslyakov [EMAIL PROTECTED] writes: MT The 16kHz cuttoff in LAME is only used at 128kbs. S By the way, Mark, if VBR falls back, let's say from 192kbps S to 128kbps or lower, does it impose this cutoff? See the sourcecode, and you will find it depends on

Re: [MP3 ENCODER] Updated LAME Benchmark Timings

Hi all, I noticed that the timings in the LAME homepage are for version 3.13. Here's some updated timings FYI: Thanks Ethan! I just added them to the web page. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )