Re: [MP3 ENCODER] Persistent JS problem, --nspsytune or not
Roel addendum: nonetheless JS influence or not, "--nspsytune" only has Roel negative implications on the -V1 (-q1) I use. Perfectly possible 128k Roel sounds better, just wanted to express that imo -V1 does not. Roel Roel I don't know what the cause is, but the improvements on lower bitrates Roel are at cost of sound quality degradation on higher ones. I can't hear the joint stereo noise you mentioned. Maybe this is because there is differences among individuals on perception of sound. So, I can't fix it directly. Since there is no problem currently in regular stereo mode, I believe the problem is caused by (default) psymodel of joint stereo. BTW, why do you stick to joint stereo? I think people who pays serious attention to sound quality should not use joint stereo at high bitrate, at least with current version of lame. Even FhG 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] -q1
Roel The graphs you provided show a lower noise, this because --nspsytune Roel probably. It simply sounds poor, really poor. It sounds nothing like Roel the original on my headphones. Roel Roel I use the one with the "RH extensions" from Dmitry. (thanks for all Roel the compiles and hard work Dmitry btw!) --nspsytune doesn't work correctly if RH extensions are enabled. Robert: Have RH extensions already become default? If not, I think it's confusing if there are two binaries. What are advantages of selecting options at compile time? I think 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
Ross Gargos Chode wrote: Ross Ross -V1 -mj -b128 -q2 -d -p -k -F --nspsytune --athlower -35 -X3. Ross Ross Some thoughts: Ross Ross -p -F will have no effect on sound quality. I have had mixed results with nspsytune. -X2 X3 both produce massively larger average bitrates than all the others. I've never played with -d. Can someone tell me if allowing channels to have different blocktypes has any bad side effects? ie. ISO or decoder compatibility? First, one should not specify "--athlower -35". This may significantly 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
Hi, I found a bug in the long block pre-echo control code. if (gfc-blocktype_old[chn] == SHORT_TYPE ) thr[b] = ecb; /* Min(ecb, rpelev*gfc-nb_1[chn][b]); */ else thr[b] = Min(ecb, Min(rpelev*gfc-nb_1[chn][b],rpelev2*gfc-nb_2[chn][b]) ); In the loop of chn, chn goes 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 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
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 e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CBR quality improvement
Naoki Changes I made are following: Naoki Naoki 1. Use -X1. Naoki 2. amp_scalefac_bands() amplifies only one sfb at a time. Robert compile LAME with RH_AMP, call it with -Y Robert and you get similar results. It's already Robert there for a while and features 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 included. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBRtest.wav
Robert I just looked again into our psymodel.c and Robert I'm wondering since when we activated the Robert following code: Robert I think the problems with that VBRtest.wav track are Robert because of the use of the above so called additive masking. Robert If you turn that off, it increases quality of that Robert specific test sample a lot, even with -q1 ! Robert (and the file size too ;) Robert Robert From my point of view, only the else part makes sense. With latest CVS version of lame, vbrtest.wav can be encoded perfectly using --nspsytune. 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
Hi all, I've just committed some changes to --nspsytune. Things changed are following: 1. Changed noise calculation. New --nspsytune uses total noise in a sfb to calculate noise. This calculates loudness of the noise. 2. Improved function of masking addition. 3. Improved tonality handling. Now, this uses a table to determine masking attenuation level. I hope more tuning of this table solves the vbrtest problem. 4. In CBR mode, --nspsytune turns on -X 6. Since noise is calculated in loudness, this should improve result of CBR. Maybe --nspsytune 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] The best decoders
David I read on the in_mpg123 web page that it doesn't support streaming. David Could this be your problem? David David (I haven't tried it myself, based on this information. My personal David "jukebox" is a streaming httpd server.) Sorry, I'm 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 :-((
I have already figured out why current --nspsytune spend too much bits for tonal parts. I told all of my new ideas to Takehiro, and Takehiro is now working to implement some of them. I also want to do that myself, but I'm now very busy. I have not changed JS related algorithms, so currently I have no idea why --nspsytune degrades JS quality. Roel RH My observation on a song from the artist formerly known as Prince: Roel RH - the old VBR code makes it at an average of 130 kbits with -V4, sounds OK Roel RH - turning on Naoki's psy tunings: it grew on 196 kbits, nearly 50% larger! Roel Roel I found it to do the same + introduce noise. Roel Roel RH I haven't spent much time at his tunings, but I fear that it always says Roel RH the sound is tonal, even if it's more noise like. Roel Roel I spent 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] MP3 decoder comparison
Ross Your joking aren't you? It uses about 5 times more CPU than in_mp3. On the Ross old machine I use it on (K6-200), in_mpg123 uses about 50% of CPU where Ross in_mp3 is about 10%. The advantage is slightly better sound quality. The amount of CPU load highly depends on 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/ )
Re: [MP3 ENCODER] Some observations of vbrtest problem
OK. I'll have some more experiments about this. Mark The reason you cannot use maxnoise is that the output of a lapped Mark transform (like the MDCT) with very short transform lenghts (576 and Mark 192 in our case), individual frequency information CANNOT BE TRUSTED! Mark You have to do some kind of smoothing/convolution before this Mark information is meaninfull. For example, two identical signals, just Mark phase shifted and with different low-level noise, can generate very Mark different maximum values, but to treat these signals differenty would Mark be a mistake. Mark Mark This is the real reason why the psycho-acoustic model does not do Mark spectral line-by-line calculations, but first convolves down Mark to 64 "partition" bands. (They did not use partition bands Mark just to save CPU cycles!) Mark Mark This information is then averaged (or in the case of AAC, Mark they use min max) down to the 21 scalefactor bands. Mark But what do you think of this variation on your idea? : Mark Mark1. compute psychoacoustics in the 64 partition bands Mark2. compute noise in the same 64 partition bands Mark3. adjust the scalefactors for scalefactor band N so that Mark noise masking, for all partition bands contained in band N. Mark Mark I think this is a good compromise between avenoise and maxnoise, Mark and actually 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/ )
[MP3 ENCODER] Some observations of vbrtest problem
I think it is certain that this problem is caused by noises concentrated on pure tones. A noise on a single MDCT coefficient increases as it's amplitude increases. This is because quantized values are actually values powered by 3/4. According to the theory of psychoacoustic, it is a wonder why using average noise rather than MAXNOISE succeeds. Perhaps this is the answer of this question: The reason why vbrtest problem is not apparent in most cases is that if a calculated noise of an MDCT coefficient exceeds the masking threshold of it's SFB, this means that amplitude of that coefficient is large and thus it makes larger masking itself. So, real masking of it's frequency is larger than calculated masking of it's SFB. Perhaps the most clear solution is to calculate masking of all MDCT coefficients, and use MAXNOISE. But this is too expensive. Perhaps a reasonable 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?
Jaroslav Sure. But not only metal. All music needs bandwidtw up to 100kHz. Ears Jaroslav cannot hear stable sinus frequency, but music is not sinus; music is Jaroslav impulses, that have more energy at band 20kHz, and you can hear it all (by Jaroslav not by ears and only 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
Hi Mark, Mark Right now, the spreading function Mark is normalized so that (for example) convolving s3 with a constant Mark function will not remove any energy and return the same constant. Is there any reason why energy should be preserved here? Mark After the spreading function is applied, then you can then adjust the Mark strength based on the tonality measure, and if you want a uniform Mark reduction by .7 (1.5db), it can be incorporated later. Mark (in fact, later it looks like you increase the masking by 2db, so all of Mark this could be done at that point?) Why I attenuate 3dB (0.7 != -1.5dB) here is that there is a description in Zwicker's book that peak of masking is 3dB below masker. Why I increase masking by 2dB later is that I tuned this value by listening tests. Mark it looks like a Mark comparison between peak and average energy within a partition band? Mark This is based on the theory that noise is usually has a flat Mark spectrum, while pure tones would have sharp peaks? Yes. Mark The ISO measure of tonality is based on how stationary a signal is Mark in time. Thus the ISO formula is based on measuring the change in Mark energy and phase over 3 granules: if they dont change much over these Mark 3 granules, the signal is considered very tone-like, and if they Mark change a lot, noise-like. Yes, I know. But, in my experiments, the ISO tonality doesn't work as I expect. I want to detect following : In Zwicker's book, there is a description that masking made by a pure tone is less than that made by noise spreading through a critical band, even if total energy of them are same. And, if there are 5 or more pure tones with same energy exist within a critical band, this can be treated as a noise. Mark 3. Simultaneous masking: This is based on the theory that Mark two maskers, when added together, can (but not always?) give Mark more masking then if the sum of their individual maskings. Yes. Mark I haven't looked at Zwicker's book (Lincoln's reference for this) Mark but I imagine it is based on tests with just 1 or 2 maskers. The description in Zwicker's book is basically based on 2 maskers. But, there is also a description that someone confirmed that the theory is also valid if there are 4 maskers. At least, it's worth trying. Mark 4. Your point #5 above is very similar to the ISO formula Mark which is implemented via "minval" threshold. The strength Mark of the maskings (computed based on tonality) is not allowed Mark to exceed a certain threshold. The ISO formula is a little Mark more complicated in that this threshold depends on frequency: Mark for low frequencies, minval is more restrictive (resulting Mark in less masking than would be used w/o minval). I can't understand necessity of minval. Mark The real goal is to find something that will increase Mark the bitrate of vbrtest.wav, without disturbing the bitrate Mark of other samples which sound ok with VBR. Yes, that is what I want to do. And, I think that this is somewhat achieved. I agree that there is room for improvements. I think that the original -V 4 is not perfect in many inputs. I can hear subtle noise which doesn't disappear with -V2 (e.g. vioo10_2.wav in SQAM). With -V 4 --nspsytune, these noise completely disappers. Increasing NTHRE produces same kind of noise with --nspsytune, so I think this is same problem as vbrtest. So, I think increase of bitrate is not so bad. I want to hear other people's opinion about quality. BTW, right now I had some listening tests that disables MAXNOISE (changing NTHRE to 10). This produces files whose bitrate a little less than without --nspsytune in average, and I cannot hear quality degradation compared to that without --nspsytune. So, I don't think I am doing completely incorrect things. Mark I've played with MAXNOISE and do not really like it since it is based Mark on inaccurate energy estimates of single MDCT coefficients, rather Mark than some kind of averaging. For example, take a signal with a very Mark large N'th coefficient. A tiny change in this signal can easily move Mark the energy so that it is now 50%/50% between N and N+1 coefficients. Mark The thing that doesn't change is the total energy. Thus I think some Mark type of smoothing needs to be done. A better solution might be to Mark take the maximum of a moving average of 5 coefficients over all the Mark coefficients in the band. Why energy is important here? I think more important thing is that peak noise must not exceed masking. 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/ )
[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/ )
Re: [MP3 ENCODER] --nspsytune
Mathew 1. Addition of simultaneous masking. Mathew Mathew What does this one mean? If there are two or more maskers, produced masking threshold is not just an addition of them, but more than that in most case. I coded this. This page explains same thing, but the formula I used is not same as that on this page. http://ccrma-www.stanford.edu/~bosse/proj/node20.html#SECTION00042600 -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] --nspsytune
Hi, I have just commited changes to add --nspsytune option. With this option, vbrtest.wav is encoded perfectly, and encoded sound becomes more natural to my ear though encoded file size increases. --nspsytune command line option turns on following things 1. Addition of simultaneous masking. 2. MAXNOISE is selected if max/avg exceeds predefined threshold. 3. long block fft window function is changed to blackmann window. 4. new tonality measure is introduced, since it seems that old tonality is not working correctly. 5. Usage of tonality is changed. If tonality exceeds 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
I tested it on some machines. It seems working fine on these machines. Followings are time needed to encode a certain file. Left side is the time when the hack is disabled, and right side is when enabled. Upper side is the time when no option is given to lame, and lower side is when '-h' option is given. I didn't change compile options. linux 2.2, gcc 2.95.2 on alpha 21164 11.049 - 10.338 -h 11.540 - 11.469 linux 2.2, gcc 2.95.2 on alpha 21264 7.314 - 6.909 -h 7.962 - 7.839 SunOS 5.6, gcc 2.7.2.3 on Ultra Sparc II 8.69 - 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
Shawn 2- Resample the input file to something ridiculously low like 40Hz, subtract this from the original WAV. (Although that would probably require the above method anyway.) Assume that the original sampling frequency is f. Downsampling to sampling frequency f/n (n is integer) 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 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] 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/ )
[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/ )
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
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] 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/ )
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 mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Speeding up window_subband
Hi all,
The patch included in this mail speeds up old filter_subband(), and It
seems that same speed-up can be applied to current window_subband(). I
tried to understand how current window_subband() works, but I couldn't.
Someone, please explain it.
Naoki
*** filterbank.c~ Mon Nov 8 10:58:50 1999
--- filterbank.cSat Apr 29 13:23:56 2000
***
*** 208,213
--- 208,305
/
+ void idct32(double a[])
+ {
+ /* returns sum_j=0^31 a[j]*cos(PI*j*(k+1/2)/32), 0=k32 */
+
+ static double costab[] = {
+ 0.5006029982351962726 ,0.74453627100229857749,0.553103896035421
+,1.4841646163141661852,
+
+0.51544730992262455249,0.97256823786196078263,0.62250412303566482475,3.4076084184687189804,
+
+0.50547095989754364798,0.83934964541552681272,0.58293496820613388554,2.0577810099534108446,
+ 0.53104259108978413284,1.1694399334328846596 ,0.674808341455005678
+,10.19000812354803287 ,
+ 0.5024192861881556782
+,0.78815462345125020249,0.56694403481635768927,1.7224470982383341955,
+ 0.52249861493968885462,1.0606776859903470633
+,0.64682178335999007679,5.1011486186891552563,
+
+0.50979557910415917998,0.89997622313641556513,0.60134488693504528634,2.5629154477415054814,
+ 0.54119610014619701222,1.3065629648763763537 ,0.70710678118654746172,
+ };
+
+ static unsigned char addtab[] = {
+ 1,29,31, 2, 1,25,27, 2, 1,21,23, 2, 1,17,19, 2,
+ 1,13,15, 2, 1, 9,11, 2, 1, 5, 7, 2, 0, 3, 1,
+ 1,27,31, 4, 1,26,30, 4, 1,19,23, 4, 1,18,22, 4,
+ 1,11,15, 4, 1,10,14, 4, 0, 7, 3, 0, 6, 2,
+ 1,23,31, 8, 1,22,30, 8, 1,21,29, 8, 1,20,28, 8,
+ 0,15, 7, 0,14, 6, 0,13, 5, 0,12, 4,
+ 0,31,15, 0,30,14, 0,29,13, 0,28,12,
+ 0,27,11, 0,26,10, 0,25, 9, 0,24, 8,
+ };
+
+ static unsigned char buttab[] = {
+ 15,31,30, 14,30,30, 13,29,30, 12,28,30,
+ 11,27,30, 10,26,30, 9,25,30, 8,24,30,
+ 7,23,30, 6,22,30, 5,21,30, 4,20,30,
+ 3,19,30, 2,18,30, 1,17,30, 0,16,30,
+ 23,15,29, 22,14,29, 21,13,29, 20,12,29,
+ 19,11,29, 18,10,29, 17, 9,29, 16, 8,29,
+ 7,31,28, 6,30,28, 5,29,28, 4,28,28,
+ 3,27,28, 2,26,28, 1,25,28, 0,24,28,
+ 27, 7,27, 26, 6,27, 25, 5,27, 24, 4,27,
+ 19,15,26, 18,14,26, 17,13,26, 16,12,26,
+ 11,23,25, 10,22,25, 9,21,25, 8,20,25,
+ 3,31,24, 2,30,24, 1,29,24, 0,28,24,
+ 29, 3,23, 28, 2,23, 25, 7,22, 24, 6,22,
+ 21,11,21, 20,10,21, 17,15,20, 16,14,20,
+ 13,19,19, 12,18,19, 9,23,18, 8,22,18,
+ 5,27,17, 4,26,17, 1,31,16, 0,30,16,
+ 30, 1,15, 28, 3,14, 26, 5,13, 24, 7,12,
+ 22, 9,11, 20,11,10, 18,13, 9, 16,15, 8,
+ 14,17, 7, 12,19, 6, 10,21, 5, 8,23, 4,
+ 6,25, 3, 4,27, 2, 2,29, 1, 0,31, 0,
+ };
+
+ static unsigned char swaptab[] = {
+ 1,16, 2, 8, 3,24, 5,20,
+ 6,12, 7,28, 9,18, 11,26,
+ 13,22, 15,30, 19,25, 23,29,
+ };
+
+ int i;
+ unsigned char *p;
+
+ p = addtab;
+ for(i=0;i32;i++)
+ {
+ if (p[0]) {
+ a[p[2]] = -a[p[2]] - a[p[1]];
+ a[p[1]] += a[p[1] - p[3]];
+ p += 4;
+ } else {
+ a[p[1]] = -a[p[1]] - a[p[2]];
+ p += 3;
+ }
+ }
+
+ p = buttab;
+ for(i=0;i80;i++)
+ {
+ double xr;
+ xr = a[p[1]]*costab[p[2]];
+ a[p[1]] = (a[p[0]] - xr);
+ a[p[0]] = (a[p[0]] + xr);
+ p += 3;
+ }
+
+ p = swaptab;
+ for(i=0;i12;i++)
+ {
+ double xr;
+ xr = a[p[0]];
+ a[p[0]] = a[p[1]];
+ a[p[1]] = xr;
+ p += 2;
+ }
+ }
+
void filter_subband(double z[64], double s[SBLIMIT]) {
double yprime[32];
***
*** 217,222
--- 309,315
double s0,s1;
+ #if 0
if(!init) {
init=1;
for (i=0; i16; i++) for (j=0; j32; j++)
***
*** 240,245
--- 333,349
s[31-i] = s0-s1;
}
+ #else
+ s[0] = z[16];
+
+ for(i=1;i=16;i++)
+ s[i] = z[i+16]+z[16-i];
+
+ for(i=17;i=31;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
Matthew Thinking about it, my other request would be seeking / file position Matthew support. I see there's some code already in DecodeThread that looks like it Matthew could handle seeking - it would just need tying in. Smoerk I cannot listen to live audio streams? Are you going to add this? Yes. I know that the plugin lacks many features. Please wait or help development. BTW, in_mpg123 will be worthless if decoder of winamp is debugged completely. I want perfect MP3 decoder now, so I developed it. But on the other hand I have some doubt about making effort to develop it. -- Naoki Shibata e-mail: [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
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] Decoder quality comparison [quite detailed - sorryifrepeat]
Hi, all. I also tested differences of outputs from some decoders. Output of mpg123 is almost identical to fraunhofer's, but there are some mp3 files whose outputs have quite large difference. I made a mp3 file by adding a patch to lame so that lame randomly selects block type, and output of mpg123 when decoding this mp3 file has apparently large noise. The dist10 decoder doesn't have this bug. I investigated the mpg123 code. Perhaps, problem is in dct12, dct64 and synth_1to1. Now, I'm trying to make a patch that fixes this problem, but this may take some days or more. The mp3 file can be downloaded from: http://www.geocities.co.jp/Technopolis/9674/lametest/test_short.zip And, I made a mp3 decoder plugin for winamp which is based on current mpglib of mpg123. This can be downloaded from: http://www.geocities.co.jp/Technopolis/9674/lametest/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/ )
