Re: [MP3 ENCODER] Persistent JS problem, --nspsytune or not

hG doesn't use joint stereo at high bitrate. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] Persistent JS problem, --nspsytune or not

some problem with joint stereo of lame. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] -q1

ink selecting experimental options via command line options is more handy. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] Interesting high quality settings and possible bug

tly degrade sound quality. I always used -q1 while tuning --nspsytune. I think -q1 doesn't degrade sound quality so much with --nspsytune. Theoretically, -X doesn't affect sound quality in VBR mode. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] Bug of long block pre-echo control

up to 3, but the size of array gfc->blocktype_o ld[] is 2. So, this code works incorrectly in joint stereo mode. This code should be fixed like this. if (gfc->blocktype_old[gfp->mode == MPG_MD_JOINT_STEREO ? 0 : chn] == SHORT_TYPE ) -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3

Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

Naoki> IIRC, bug of winamp is also triggered by FhG encoded mp3 file. This means that nitrane has more than one bug. So, changing IXMAX_VAL to 8191 doesn't solve all problems. I think we should investigate what FhG encoder does, and make lame do what FhG does. -- Naoki Shibata

Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!

this. Mark> This probably shouldn't be called a winamp bug or a LAME bug, Mark> but instead a unclear ISO specification. Mark> Mark> Should we change IXMAX_VAL to 8191? IIRC, bug of winamp is also triggered by FhG encoded mp3 file. And, Null soft have already almost completed

Re: [MP3 ENCODER] --nspsytune and tonality balance

Robert> You can add --raise-smr 1 to 1.) and compare again I've also compared using --raise-smr 1. As far as I tested, --nspsytune also gives better result with this setting. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] --nspsytune and tonality balance

44.1 --lowpass 16 -Y -Z -X1 2. Use lame compiled with default options. Command line options are: -h (or -q1) -b 96 --resample 44.1 --lowpass 16 --nspsytune With these extreme settings, I can hear more artifacts with 1 than 2. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 E

Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments

high tonality like piano and tambourin but sometimes degrades sound with low tonality like snare drums. In CBR mode, --nspsytune lowers artifacts in high frequency. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] CBR quality improvement

eatures some better Robert> short block noise coloring. Improvement of CBR quality is achieved only when both 1 and 2 are turned on. RH_AMP with -Y option only turns on 2. Please listen with your ears and compare. Shawn> Would that include Safe-VBR mode as well? Currently, ABR is not

[MP3 ENCODER] CBR quality improvement

coded quality of applaud.wav is now very close to that of mp3enc3.1. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] VBRtest.wav

tune. It was a problem of detecting/handling tonality. Now, as far as I tested, --nspsytune always gives equal or better result than default psymodel if their encoded file sizes are same. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] improved --nspsytune

ytune doesn't work well if fs != 44.1KHz. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] MPG123 decoder plugin for Winamp?

David> Sorry, but I can't find the address to the MPG123 decoder plugin for Winamp. David> Could anyone point me in the right direction? It's here. http://www.geocities.co.jp/Technopolis/9674/in_mpg123.html -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mai

Re: [MP3 ENCODER] Free format

Mark> Freeamp and l3dec can also handle freeformat. Sorry, in_mpg123 1.18 has a problem with free format. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] The best decoders

very busy now and can't make new version of in_mpg123. Perhaps I'll be freed by the weekend after next. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] "--nspsytune" really sounds (more than a fair amount) worse :-((

a whole afternoon (7 hours) trying and not 1 file I tried sounds better in any Roel> way. Roel> Roel> - JS files -> suffer big Q losses Roel> - S files -> seem ok -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] Some observations of vbrtest problem

Mark, would you give me more detailed explanation about this? How can I reproduce this? Mark> For example, two identical signals, just Mark> phase shifted and with different low-level noise, can generate very Mark> different maximum values, -- Naoki Shibata e-mail: [EMAIL

Re: [MP3 ENCODER] MP3 decoder comparison

een all four me ;) At least, nitrane with pentium option doesn't produce (near) perfect output. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] Some observations of vbrtest problem

simplifies the psycho acoustic model since Mark> we dont have to map from partition bands down to scalefactor bands. Mark> Mark> Mark -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] MP3 decoder comparison

performance of FPU. Since K6's FPU performance is much worse than Pentium II's, load on K6 is much higher than on Pentium II. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] Some observations of vbrtest problem

asonable solution is detecting peaks and calculating these maskings separately. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] 32 or 44.1kHz for 128 kbit/sec mp3s fromsoundcard?

y impulses, not sinus). Here are results of interesting experiments about this issue. http://www.etl.go.jp/%7Eacoustic/research/hf-e.html -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] --nspsytune

asking. I cannot explain reason now, but in my experiment using FFT, if a pure tone is located at 50%/50% between N and N+1 coefficients, drop of peak coefficient's energy is 0.9dB(I have to think it's reason, but this may because of window function). -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] --nspsytune

used is not same as that on this page. http://ccrma-www.stanford.edu/~bosse/proj/node20.html#SECTION000426000000 -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] --nspsytune

I forgot to mention: There is no advantage to use --nspsytune with CBR 128 as far as I tested. Please use --vbr-old when use --nspsytune. --nspsytune turns on -Z. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] --nspsytune

predefined threshold, masking made by that partition is suppressed by 10dB. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] square wave and vbrtest.wav problem

The vbrtest.wav problem can be reproduced with a simple square wave. http://www.geocities.co.jp/Technopolis/9674/lametest/index.html -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] hack for IEEE754 FPU

> 7.89 -h 10.46 -> 10.90 -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] default high pass filtering

r, and after 11 iterations the sampling frequency will be about 21Hz. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] default high pass filtering

ger) is easy, since this is done by picking up every nth sample. Upsampling this data to frequency f requires filter with large order, but since almost all input sample is zero, this process requires only small computational power. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER maili

Re: [MP3 ENCODER] free format bitstreams

ee format bitstreams. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] Hardware reccomendation

Segher> Oh, by the way, anyone interested in better DCT's? I made faster mdct_long and sent it to Takehiro. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] new in_mpg123

Mark> Naoki: How were you planning on adding the resync code? Mark> Would this be inside or outside of mpglib? I added it outside mpglib. It seems working fine now. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] Speeding up window_subband

7;t understand how current window_subband works, I chose not to optimize the code. Since almost all MP3 decoders use DCT version of the algorithm in subband synthesis, it should become faster than naive one, perhaps. :) -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http

Re: [MP3 ENCODER] new in_mpg123

msterdam, 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] LAME encoder plugin for WinAmp?

tml?componentId=177 -- 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. 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 ( h

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/ )

[MP3 ENCODER] new in_mpg123

-- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] Speeding up window_subband

ng faster algorithm. Have you already made it? -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] LAME encoder plugin for WinAmp?

Mark> I haven't heard of anything. But for this to be usefull, wouldn't Mark> you also need some ripping software? Ripping plugin already exists. http://www.winamp.com/customize/detail.jhtml?componentId=546 -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mai

[MP3 ENCODER] Speeding up window_subband

i++) + s[i] = z[i+16]-z[80-i]; + + idct32(s); + #endif } -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] mpglib bugfix

ort to develop it. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] mpglib bugfix

at the beginning of the function. Mark> Any chance Mark> you'd be willing to apply the fixes to mpg123/mpglib used Mark> by lame? The patch I posted is made for mpglib of lame. The original mpg123-0.59r (not mpglib version) seems to have another bug. -- Naoki Shibata e-mail:

Re: [MP3 ENCODER] mpglib bugfix

Matthew> Great stuff. I have a couple of questions/feature suggestions Thanks. Perhaps I can implement both features. Please wait for anouncement of new version. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

Re: [MP3 ENCODER] mpglib bugfix

lame, "Thompson Multimedia" should be corrected to "Thomson Multimedia". -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] mpglib bugfix

com/ProductsHeadphones/EtymoticER4Sasp.asp -- Naoki Shibata e-mail: [EMAIL PROTECTED] patch

Re: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorryifrepeat]

t/in_mpg123.zip > WinAmp's EQ sucks bigtime. They all have the same frequency response. Try my EQ plugin for winamp. It can be downloaded from DSP plugin section of winamp.com. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )

[MP3 ENCODER] a bug of lame 3.50

Hello. I found a sample that lame 3.50 compresses worse than iis's. See here: http://www.geocities.co.jp/Technopolis/9674/lametest/index.html Best Regards -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )