RE: [MP3 ENCODER] TagItem issues...
-Original Message- From: David Balazic [mailto:[EMAIL PROTECTED]] Sigbjrn Skjret wrote: /* in my man page va_start has only one argument (ap) ... */ Your man-page is wrong then I think, the second argument is so that va_arg() knows where to start (ie, it makes ap point to the next argument). HP-UX 10.20 man varargs say that it has only one arg. /usr/include/varargs.h on the same system has definitions with both two or one argument. Which one is used is dependent on some preprocessor variables ( platform/CPU type , I guess ). A linux libc5 system has a definition in include files with one arg too. varargs.h is pre-ANSI and non-standard - use stdarg.h for the standard stuff. Should be va_start(ap) va_arg(ap, type) -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] castings
From: "Frank Klemm" [EMAIL PROTECTED]
#include stdio.h
float x1 = 1.e30;
float x2 = 1.e31;
float x3 = 1.e32;
int main ( void )
{
float x4;
x4 = x1*x2*x3 / (x1*x2 + x2*x3 + x3*x1);
printf ( "%g\n", x4 );
return 0;
}
The code line x4=... is equivalent to
x4 = (float) ((double)x1*x2*x3 / ((double)x1*x2 + (double)x2*x3 +
(double)x3*x1));
No, that would be very bad for machines without hardware 'double' support.
KR1 did require that behaviour, though. (The change is explicitly noted in
KR2).
Note, that the optimizer of gcc-2.95 isn't standard conform.
I don't doubt it. :)
One exception for implicit type conversations are functions calls of
prototyped
functions (Note: Not in KR2, but in ANSI C3.159-1989 and later).
Exception from what?
PS: Nice try for MS VC++:
unsigned __int64 x = 123456789012345LL;
doubley;
y = x;
Didn't they finally fix that in SP3?
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] castings
From: "Frank Klemm" [EMAIL PROTECTED] a) char, signed char, short = int unless int cannot represent all possible values of char, in which case char = unsigned int b) unsigned char, unsigned short = unsigned int if int can represent all possible values unsigned char, unsigned short = int otherwise unsigned char, unsigned short = unsigned int In essence, objects of type "smaller" than int are converted to int, unless int can't represent all values, in which case they're converted to unsigned int. Horribly platform-dependent. c) float = double No. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] gcc option for TAKEHIRO_IEEE754 hack
From: "Sigbjørn Skjæret" [EMAIL PROTECTED] I just made a new TAKEHIRO_IEEE754_HACK more ANSI C compliant. I think we can make it default for Intel architecture. This seems to work fine for PPC now (giving a speedboost of 10-15%), but 68k still doesn't work (tons of reservoir errors), IIRC, 68k doesn't use IEEE754 format at all - Motorola used a floating-point format of their own. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Time-stretching (off topic)
From: "Steve Lhomme" [EMAIL PROTECTED] Resampling just add/delete samples from the original If you mean that literally, that's a very bad way to do it. :) Take a look at SoX, which provides several resampling algorithms with different tradeoffs. I think the resampler in LAME is roughly "mid-range" against those in SoX. Time stretching is the same operation, but in practice I guess the noise shaping should be different, on psychoacoustic[al?] grounds. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame source C++ compatible?
From: "David Balazic" [EMAIL PROTECTED] C++ is a superset ( more or less ) of C , so it should handle C code. In terms of features that's broadly true for C89, but differences in the type system, operator precedence and the the set of reserved/key words are enough to make porting a chore, usually an unnecessary one. Then you have C99 with a pile of features that C++ lacks, such as variable-length arrays. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib compiles once again...
From: "Pierre Hugonnet" [EMAIL PROTECTED] There is still something that I don't understand: layer3 'contains' layer2, which in turns 'contains' layer1. No, they aren't related in that way. They were developed more or less in parallel for different applications(delay, complexity, bitrates, etc.), so although they share some ideas/structure, they do not "contain" one another. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Please stop breaking LAME... ;)
From: Frank Klemm [mailto:[EMAIL PROTECTED]] Good C Code should be compilable with (nearly) all C(89/95/99) Agreed. (Although there is some perfectly good C89/95 code that is broken by changes in C99 - see endless arguments in news:comp.std.c) and C++ compilers. Good C code compilable as C++ tends to be *bad* C++ code, so why bother? Let the two languages concentrate on what they're good at... But if you're intent on compiling C with a C++ compiler, an automated translator is probably the best approach: you don't need to break/weaken/obfuscate your C code that way. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] linux lossless encoder
From: "Scott manley" [EMAIL PROTECTED] You should search for a prgaram called 'Shorten' this is also a lossless compressor for Unix (free for unix Free only for non-commercial use, I think. - but you pay for the windows version) The "Linux version" can be compiled for Windows with a few small changes (I/O stuff). -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame source C++ compatible?
From: "Segher Boessenkool" [EMAIL PROTECTED]
How to compile lame on a system where only a C++ compiler is available
(the
C compiler costs extra money)? Currently lame generates nearly
uncountable
errors with a C++ compiler.
Put
extern "C" {
}
around everything? (Around a whole file is ok, I believe).
That only affects the linkage of functions (e.g. disables name mangling).
There's no easy way to do it in general. I've done it a few times for some
fairly large pieces of code, and it's no fun at all. Then there's the
maintenance...
Is the C compiler expensive? :)
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] sync-word (Was Free Format problem)
From: "Shawn Riley" [EMAIL PROTECTED] Alex wrote: Thus, I surmise that there are no 405 byte frames - you just aren't tracking syncs correctly. Does that mean that each frame has to have a whole number of bytes Yes, Layer III works with 8-bit "units". therefore that the sync-word is only allowed to start on the first bit of any byte? Normally yes, but I guess it could become misaligned if the stream were corrupted in transit... would be interesting to see how many decoders can cope with that. :) -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Digital downsampling of mp3s?
From: Stephen Kennedy [mailto:[EMAIL PROTECTED]] Is it possible to have lame digitally resample an mp3 on a frame-by-frame basis? Although granted, the quality wouldn't be as good as a 'slow' encoding, I'd imagine this could be extremely fast! Hmmm, I doubt it. The psychoacoustic model needs the original signal in (at least) FFT form. I don't think MDCT - FFT can be done directly, so you'd need to go MDCT - time domain - FFT, i.e. full decode followed by FFT. You probably wouldn't gain any speed at all. I suppose you could disable the psymodel, but at low bitrates that's a recipe for terrible quality... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] can Lame Joint Stereo be improved?
From: Roel VdB [mailto:[EMAIL PROTECTED]] 3) QD mp2 fast : terrible, where did the frog come from ?? 4) QD mp3 HQ : total mutilation, yeah! spacey effects, this is the worst around. I think would sound like this when a robot has sex. 5) QD mp2 HQ : low pounding distortion, L channel in start 6) QD mp3 fast : L channel is lost: sounds like there is an extra instrument introduced. Or maybe it has been through a WMA filter or so. complete hollow sound. Which version of the QDesign coder is this? With the last version of MVP I tried, "fast" and "high quality" modes produced identical output for both MP2 and MP3. BTW, you can test FhG JS @ 192kbit/s with AudioActive Production Studio 2.x. (All other recent implementations switch to stereo at 160). -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Multi PCM file coding and decoding
From: Frank Klemm [mailto:[EMAIL PROTECTED]] Gaps at the start and end are always removable by the encoder. Only if you act stupid, the gap is unavoidable. ... For that lame must encode a collection of files at once. In that case you haven't avoided the gap: you've simply filled it with a fragment of another track. Not really a solution, unless you plan to always play back the tracks in the same order. But then, why split them into separate tracks at all? :) I think the cleanest solution would be a small addition to ID3, with coder delay and original track length stored along with the other info. The delay could be defined as (say) total delay of encoder + dist10 decoder, which should be unambiguous and easy to calibrate against. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] ABX Tool
From: Frank Klemm [mailto:[EMAIL PROTECTED]] Is there a ABX tool out there? A simple one is enough. http://www.pcabx.com Plenty of ready-encoded test signals there, too... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] M/S encoding ?
From: David Balazic [mailto:[EMAIL PROTECTED]] In short : M/S mode might consider parts of music masked, that would not be masked in regular stereo mode. This seems wrong to me, alltough is is possible that the brain would do this masking itself. Ever used a phone in a loud environment, and had to block one ear to hear it? Now tell me there is no masking between channels. :) In any case, MS and stereo are only ways of storing the audio. The psychoacoustic model could exploit inter-channel masking in both cases... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi PCM file coding and decoding
From: "DataFlow" [EMAIL PROTECTED] then why do all encoders add this gap? anyone knows this? Check the archives of the list: Mark Taylor wrote quite a lengthy explanation a while back. Maybe it's on the web site too. IIRC, the delay at the beginning can be removed, but would result in attenuation (decrease in volume) in the first frame. The delay at the end is unavoidable unless you have some way of transmitting the exact length of the original file. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Multi PCM file coding and decoding
From: Frank Klemm [mailto:[EMAIL PROTECTED]] I know there is a project to avoid pauses between tracks by extending the MP3 format with additional tags. But I don't understand why this is necessary and AFAIS the handling is a little bit difficult. [snip suggested support for multiple filenames] This seems to assume that you have to encode each track individually. Why not use one big wav, encode that, and split it afterwards? This requires no encoder changes (will work with any encoder) and the tools already exist to do the splitting. Works for me... but I'm idly working on an "encoder wrapper" that simplifies the process wrapper file.wav file.cue will first invoke the encoder on file.wav, producing file.mp3, then split file.mp3 based on file.cue, adding id3 tags as it goes. It would then be quite simple to add support for your approach wrapper file1.wav [file2.wav [...]] and work with a cue sheet generated on the fly. Seems to me to be a cleaner approach overall. OTOH I'm not sure if .cue files are well-supported on platforms other than Windows. Can cdparanoia etc. be configured to generate them? -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] old VBR now faster
From: "David Bridson" [EMAIL PROTECTED] While we're on the subject of VBR, I have one question about LAME: why does it only support such a limited number of bit rates. I've seen VBRs made with other encoders that don't rely just on a few bit rates but precisely adjust the bit rate according to the complexity of the music. No they don't. All VBR encoders I'm aware of (and I think I've seen all of them) use the standard MPEG bitrates, as displayed by lame --longhelp. If you see any other bitrates then your player is fooling with you. :) The only way to get more precise bitrate selection is to use free format, and free format doesn't support VBR. MP3's bit reservoir limits free format's usefulness in any case - even if you "overcommit" bits in one frame, you can make use of the slack in following frames. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Off Topic Advice Please
From: "Mark Stephens" [EMAIL PROTECTED] isn't LAME higher quality at a faster speeds? The new FhG codec at high speed isn't very good, I thought, or is there proof otherwise? IMO FhG's "fast" encoder is the best around for lower bitrates - 160kbit/s and below. But the heuristic they're using fails at higher bitrates. FhG themselves say === Two codecs are provided, the default being the fastest and high quality as well. Most of the time, youll want to use this codec when doing CBR encoding. The Alternate codec may however work better on some material (or it may not). It generally has slightly better temporal resolution (which can be heard by more presence in the high end at times). But the encoding speed is much slower, especially in High mode. The Alternate codec also improves at rates of 160kbps or greater. Both codecs have their advantages and disadvantages: try using the first codec (the default) and only try the second codec if you are having problems with sound quality. === In my experience, the "alternate" codec does tend to produce obvious artifacts at lower bitrates - ringing, flanging, etc. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] RE: Layer 2 vs Layer 3 (was RE: 2MP3 from cassette at LAME 3.85)
From: Jaroslav Lukesh [mailto:[EMAIL PROTECTED]] I put package for cooledit (it works with cooledit 2000, confirmed by friend) from syntrillium at our corporate web at www.k-net.cz/!/lossaud.zip (564k) Here are MP3 decoder, source, MP2 encoder and decoder, [...] Isn't this a straight port of ISO dist10? You may get better results with toolame or QDesign's MP2 encoder (available free with MVP). On MP2's allegedly higher quality than MP3 at high bitrates, I can hardly ever tell the difference at such bitrates anyway. But looking at objective measures, LAME @ 320kbit/s gives significantly lower noise than any MP2 encoder I've seen, even at 384kbit/s. However, I don't have access to the hardware encoders you speak of, or to the Philips Power Library, which is apparently very good. (BTW, anyone know much about QDesign's own audio format? It seems to be used quite heavily by QuickTime movies, but the quality wasn't too impressive when I tried it - roughly on a par with WMA, bitrate for bitrate). -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Down-encoding of MP3 data
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Given a high bitrate encoding of a track, is there a good way to produce a lower bitrate encoding from it? lame --mp3input -h -b 96 highbitrate.mp3 lowbitrate.mp3 Does MP3 data allow mathematical magic to produce a lower bitrate file without having to go back out to a WAV file and be re-encoded? For example, if data is encoded at CBR 192, is there some transformation on the data that can quickly give CBR 96? No. There are some small savings that can be made, but the most expensive parts of encoding (quantization, psychoacoustics, bit packing) need to be completely redone for best results. You can't simply "throw more bits away". :) And if encodings are made from other encodings, are there artifacts that might appear? Yes, because the encoder no longer has access to the original data - the psychoacoustics will be comparing to data that is already "damaged". If you're lowering the bitrate to 96kbit/s, you're likely to get some distortion anyway; this will only make it worse. An MP2 developer at Philips advised me that if you intend to cascade code MP2 data, you should use an initial bitrate about 20kbit/s higher than you would normally use. I'm not sure what the corresponding figure would be for MP3, but it's better to avoid cascaded coding entirely. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Lame development matures ...
From: Monty [mailto:[EMAIL PROTECTED]] I myself bought a good pair of Sennheiser HD-490 headphones ($45, belgium) and a sb128 soundcard ($25, nice linear play and high S/N ratio(linux compatible, ensoniq)). Another set of very good, reasonably priced headphones are the Grado Labs SR80s (my personal price/performance favorites at roughly $80). Grado are good, as are Beyerdynamic. I have DT331s (80UKP) at home and DT75s (35UKP) at work. Both are very light and comfortable. I've tried several pairs of Sennheisers, and found them bass-heavy and uncomfortable. YMMV. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --nspsytune
From: "Naoki Shibata" [EMAIL PROTECTED] --nspsytune command line option turns on following things 1. Addition of simultaneous masking. What does this one mean? 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. Ouch, lots more variables to consider. :) -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Problems under MSVC 6
From: Karsten Luetkewitz [mailto:[EMAIL PROTECTED]] I grabbed the latest CVS source for 3.56 and compiled it with [...] MSVC standard edition. [...] I played around with compiling options in both files but got no higher than 1.2x realtime. I don't have any clue what optimal options to choose to achieve higher rates ... If anyone has a hint what options produce the fastest result in MSVC I'd be grateful. The Standard edition doesn't include an optimizing compiler, so you're unlikely to get a lot of speed out of it. Try the 30-day evaluation version of Intel's compiler at http://developer.intel.com/vtune/ . Makefile.MSVC has a special set of options for it. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Why I think 3.84a-Z should become 3.84 beta ...
At 13:28 28/06/2000 +0200, Roel VdB wrote: now I have to make some (unnecessary imho) major adjustments to my site, in order to get this explained to the layman lame user. Alpha versions are not intended for laymen, so maybe it was a mistake to base your site around them in the first place. Or maybe you need two sites. :) -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Mark's new VBR now the default
From: Robert Hegemann [mailto:[EMAIL PROTECTED]] Mathew Hendry schrieb am Fre, 23 Jun 2000: The -Y mode does seem to have problems, though. A five minute test track I just encoded at -v 4 has spurious bleeps all the way through it. Smells more like a logic error than a problem with the psychoacoustics. -- Mat. Hmm strange. I don't know what you mean with "spurious bleeps". Short, loud pulses at fairly low frequencies (a few kHz). There were about 20 of them through the track. Not random: they seem to be concentrated in certain parts of the track. All my tracks I encoded with Mark's new VBR routine where of better quality than with the old VBR. Maybe you could send me a short excerpt of your test track? I'll have another look this evening when I get home. Could simply be Intel's compiler glitching out again... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] ACM (2)
From: Ross Levis [mailto:[EMAIL PROTECTED]] apparently the Windows ACM doesn't support VBR and I think it was abandoned. I'm not sure where the problem is because I'm fairly sure that the Fraunhofer ACM does play VBR MP3 WAV files. It does, because the *output* is CBR. That's where the limitation lies. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Marks new VBR now the default
At 12:00 23/06/2000 +1200, Ross Levis wrote: That's a controversial move IMO. The advantage of true VBR is that more complex recordings use higher bitrates and less complex have low bitrates and filesizes with roughly the same amount of distortion. With Marks ABR the operator chooses the bitrate, so complex recordings have high distortion, and less complex recordings are wasting disk space. By "Mark's new VBR" he means -v -Y mode, not --abr. The -Y mode does seem to have problems, though. A five minute test track I just encoded at -v 4 has spurious bleeps all the way through it. Smells more like a logic error than a problem with the psychoacoustics. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] ACM (2)
At 12:16 23/06/2000 +1200, Ross Levis wrote: Mathew Hendry wrote: From: Ross Levis [mailto:[EMAIL PROTECTED]] apparently the Windows ACM doesn't support VBR and I think it was abandoned. I'm not sure where the problem is because I'm fairly sure that the Fraunhofer ACM does play VBR MP3 WAV files. It does, because the *output* is CBR. That's where the limitation lies. Of course the output will be CBR. As I understand it, all sounds regardless of codec are effectively decoded to PCM before being sent to the soundcard. So where is the limitation then? In the output, which must be CBR... ACM can't produce VBR output, so it can't produce VBR MP3s. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] BT claims patent on internet links
And you thought FhG was bad. :) http://news.bbc.co.uk/hi/english/sci/tech/newsid_798000/798475.stm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] 22/56/JS - Lame vs Fraunhofer
From: Shawn Riley [mailto:[EMAIL PROTECTED]] I forgot to add that Fraunhofer also sounded better at 48k than Lame did at 56k... Maybe this filtering is why. Also, Fraunhofer use intensity stereo at low bitrates. Maybe you could compare LAME with FhG -no-is. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mp3enc 3.1 and -l3wav
From: "Ampex" [EMAIL PROTECTED] anyone running mp3enc 3.1 under windows, does the -l3wav parameter crash it every time? Just tried it here (Win2k, Celeron 400), no problems. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Problems enabling MMX with MSVC 5
From: "Joshua Bahnsen" [EMAIL PROTECTED] I defined "MMX_choose_table" using MSVC 5 and I came across problems in takehiro.c. It said, "long" followed by "long" is illegal. I compiled it with DJGPP with MMX support enabled and it compiled without any errors in takehiro.c. For 64 bit integers, DJGPP (gcc in general) uses the type "long long" whereas MSVC 6 uses "__int64". I'm not sure if MSVC 5 supports it. If it does, some new typedefs for machine.h would be the way to fix it. After that, i386/choose_table.nas might need some attention... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame3.84 (CVS) in pipelines b0rken since 23.May
From: "Takehiro Tominaga" [EMAIL PROTECTED] "M" == Mathew Hendry [EMAIL PROTECTED] writes: M I got Takehiro's code working (the fp stack was out of order) M but it seems to be slightly slower than the original. Here's M the fixed code anyway - the main loop in quantize_xrpow slow umm What kind of architechture you use ? Sorry, should have mentioned I'm using a Celery 400 / Win2k. The difference in speed is small but consistent. if P6 (dynamic execution arch.), it stalls continuous fmul section. if P5 or K6-2/III, it can't speed up by fxch pipeline hack. Maybe Acy Stapp can help out here. His original MSVC code was aimed at P6, but I think he made some comments about changes for P5 when he posted the patch. My gcc code was a conversion of that. Anyway, I am now replacing these asm routines into GOGO's more aggressive code. 3DNow!/SSE will bring us a crazyly fast encoding. Bah, and I don't have either of those extensions... still waiting for decent dual K7 boards to appear. ;) -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame3.84 (CVS) in pipelines b0rken since 23.May
From: "Mark Taylor" [EMAIL PROTECTED]
The code enabled by
#define USE_GNUC_ASM
is currently broken. Takehiro was trying some improvements,
(Takehiro, maybe you could revert CVS back to the original until
these are working? )
I got Takehiro's code working (the fp stack was out of order) but it seems
to be slightly slower than the original. Here's the fixed code anyway - the
main loop in quantize_xrpow
{
__asm__ __volatile__(
"\n\nloop1:\n\t"// 0 1 2 3 4
"fld" F8type " 0*" F8size "(%1)\n\t" // 0 i
"fmul %%st(1)\n\t"
"fld" F8type " 1*" F8size "(%1)\n\t" // 1 0 i
"fmul %%st(2)\n\t"
"fld" F8type " 2*" F8size "(%1)\n\t" // 2 1 0 i
"fmul %%st(3)\n\t"
"fld" F8type " 3*" F8size "(%1)\n\t" // 3 2 1 0 i
"fmul %%st(4)\n\t"
"fxch %%st(3)\n\t"// 0 2 1 3 i
"fistl (%3)\n\t"
"fxch %%st(2)\n\t"// 1 2 0 3 i
"fistl 4(%3)\n\t"
"fxch %%st(1)\n\t"// 2 1 0 3 i
"fistl 8(%3)\n\t"
"fxch %%st(3)\n\t"// 3 1 0 2 i
"fistl 12(%3)\n\t"
"addl $4*" F8size ", %1\n\t"
"addl $16, %3\n\t"
"dec %4\n\t"
"movl -16(%3), %%eax\n\t"
"movl -12(%3), %%ebx\n\t"
"fxch %%st(2)\n\t"// 0 1 3 2 i
"fadd" F8type " (%2,%%eax," F8size ")\n\t"
"fxch %%st(1)\n\t"// 1 0 3 2 i
"fadd" F8type " (%2,%%ebx," F8size ")\n\t"
"movl -8(%3), %%eax\n\t"
"movl -4(%3), %%ebx\n\t"
"fxch %%st(3)\n\t"// 2 0 3 1 i
"fadd" F8type " (%2,%%eax," F8size ")\n\t"
"fxch %%st(2)\n\t"// 3 0 2 1 i
"fadd" F8type " (%2,%%ebx," F8size ")\n\t"
"fxch %%st(1)\n\t"// 0 3 2 1 i
"fistpl -16(%3)\n\t"// 3 2 1 i
"fxch %%st(2)\n\t"// 1 2 3 i
"fistpl -12(%3)\n\t"// 2 3 i
"fistpl -8(%3)\n\t"// 3 i
"fistpl -4(%3)\n\t"// i
"jnz loop1\n\n"
: /* no outputs */
: "t" (istep), "r" (xr), "r" (adj43asm), "r" (ix), "r" (576 / 4)
: "%eax", "%ebx", "memory", "cc"
);
}
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Various
From: Shawn Riley [mailto:[EMAIL PROTECTED]] 6- What's the difference between normal stereo dual channel In terms of bitstream format, nothing, apart from the frame header. Dual channel is simply a hint to the decoder that the two channels are intended to be played separately, rather than together as a stereo track. normal stereo allowing a more "free" allocation of bandwidth between the channels? AFAIK it doesn't. I'm not sure where that idea originated. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Various
From: Gabriel Bouvigne [mailto:[EMAIL PROTECTED]] In dual channel, each channel has to got exactly half of the bits. Do you have a reference for that in the ISO/IEC docs? Throughout 11172-3 stereo and dual_channel seem to be treated as entirely equivalent. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Various
From: Ross Levis [mailto:[EMAIL PROTECTED]] I have been under the impression for several years that Stereo (mode 0) shares bits between the channels. If one channel was more complex than the other then it would allocated more to the channel that required it. I presume this is what LAME is doing, is it not? Yes it is. The question is whether dual_channel is more restricted than that. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] MPEG layers
From: Segher Boessenkool [mailto:[EMAIL PROTECTED]] Layer II does _not_ have: window switching (short blocks) hybrid transform (mdct stuff) bit reservoir It _does_ have: much better scalefactors (more finegrained) The layer II scalefactors are a lot cheaper most of the time, and sometimes you pay a lot for saving too much :-( Any other differences I'm forgetting? MS Stereo and entropy coding in Layer III. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MPEG layers
From: "Segher Boessenkool" [EMAIL PROTECTED] But doesn't layer II have mid/side stereo (as well as intensity stereo)? Nope, mid/side is only available in Layer III. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] MP3Enc upsampling
Any guesses as to why MP3Enc 3.1 upsamples to 48kHz by default at 320kbps? To increase time resolution? -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] definition of kbps
From: "Taupter" [EMAIL PROTECTED] [...] the right case for multipliers is uppercase (K, M), [...] ITYM all multipliers except k - kHz, km, etc. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] definition of kbps
From: Taupter [mailto:[EMAIL PROTECTED]] Mathew Hendry wrote: From: "Taupter" [EMAIL PROTECTED] [...] the right case for multipliers is uppercase (K, M), [...] ITYM all multipliers except k - kHz, km, etc. No. Surely KHz, Km, et cetera el al. Nope, however sensible that might be. One reference http://physics.nist.gov/cuu/Units/prefixes.html Also see http://physics.nist.gov/cuu/Units/binary.html Apparently we should now be talking about "mebibytes" (MiB) of memory rather than megabytes :) -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] definition of kbps
From: Jack Moffitt [mailto:[EMAIL PROTECTED]] networks are measured with k = 1000. storage is measured with k = 1024. this is how it has traditionally been. It seems to be quite common to use the prefix "K" to refer to multiples of 1024, and "k" for mutliples of 1000, but I don't know if this is formalised anywhere. Similarly "B" for bytes and "b" for bits... 64KB of memory vs. 64kbps MP3. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] decoder tests
From: "Mark Taylor" [EMAIL PROTECTED] Could someone re-post that email with the decoder quality comparisons? I lost it (and I cant remember who did the work), and it must have been posted during the month when the mp3encoder mailing list archive was down. This one? (Two messages from about a month ago) Very simplistic tests... - Original Message - From: "Mathew Hendry" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 17, 2000 4:25 PM Subject: Re: [MP3 ENCODER] Best decoder? From: "Felix von Leitner" [EMAIL PROTECTED] Excuse me, but what can you do incorrectly when decoding an mp3 stream? It seems there are plenty of things that can go wrong. :0 I took a simple (stereo) mixture of sine waves (1kHz, 2kHz, 4kHz, 8kHz, 16kHz) and encoded them with mp3enc @ 320kbps, qual 9, 44100Hz. I decoded this signal with l3dec, winamp and sonique. First thing I noticed is that sonique's decoder *inverts* the signal, which isn't very impressive. I then compared the decoded Mp3s to the original. Following are some statistics on the delay-adjusted difference signals - sonique does relatively badly. l3dec and winamp are almost identical. (RMS figures use a 50ms window). L3Dec -- Left Right Min Sample Value : -367 -363 Max Sample Value : 366 366 Peak Amplitude : -39.02 dB -39.04 dB Possibly Clipped : 0 0 DC Offset: 0 0 Minimum RMS Power: -47.10 dB -47.11 dB Maximum RMS Power: -40.05 dB -40.05 dB Average RMS Power: -45.47 dB -45.47 dB Total RMS Power : -45.22 dB -45.22 dB Winamp -- Left Right Min Sample Value : -367 -364 Max Sample Value : 366 369 Peak Amplitude : -39.00 dB -38.96 dB Possibly Clipped : 0 0 DC Offset: -.002 -.002 Minimum RMS Power: -47.10 dB -47.11 dB Maximum RMS Power: -40.05 dB -40.05 dB Average RMS Power: -45.47 dB -45.47 dB Total RMS Power : -45.22 dB -45.22 dB Sonique (after compensating for inversion) --- Left Right Min Sample Value : -877 -877 Max Sample Value : 819820 Peak Amplitude : -31.45 dB -31.45 dB Possibly Clipped : 0 0 DC Offset: 0 0 Minimum RMS Power: -42.09 dB -42.08 dB Maximum RMS Power: -37.66 dB -37.66 dB Average RMS Power: -39.92 dB -39.92 dB Total RMS Power : -39.84 dB -39.84 dB In FFT analysis, the sonique difference signal is generally noisier overall, with the 2kHz noise peak being at least *12dB* higher than the corresponding peak in the l3dec and winamp versions. -- Mat. - Original Message - From: "Mathew Hendry" [EMAIL PROTECTED] To: "MP3 Encoder" [EMAIL PROTECTED] Sent: Friday, March 17, 2000 9:09 PM Subject: Fw: [MP3 ENCODER] Best decoder? Sending this again. Didn't seem to get through the first time. (It never arrived here, at least). - Original Message - From: "Mathew Hendry" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, March 17, 2000 5:04 PM Subject: Re: [MP3 ENCODER] Best decoder? From: "Gabriel Bouvigne" [EMAIL PROTECTED] Wich sonique? 1.5 or lower? Sorry, that was 1.30.4, the latest non-beta release. I finally persuaded 1.5 beta to work (it's very unstable) and its results are identical to those of L3Dec: Sonique 1.5 -- Left Right Min Sample Value : -367 -363 Max Sample Value : 366 366 Peak Amplitude : -39.02 dB -39.04 dB Possibly Clipped : 0 0 DC Offset: 0 0 Minimum RMS Power: -47.10 dB -47.11 dB Maximum RMS Power: -40.05 dB -40.05 dB Average RMS Power: -45.47 dB -45.47 dB Total RMS Power : -45.22 dB -45.22 dB When directly comparing the L3Dec and Sonique 1.5 outputs, the maximum difference between the two was +/- 1 LSB, which I guess can be attributed to differences in dithering. I was surprised at the poor results from the old Sonique, though, since it seems to have acquired a reputation as the best quality player (even before these latest betas). -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
From: "Hudson Kingery" [EMAIL PROTECTED] Has anyone found examples of music that are not transparent at 256k or 320k? castanets.wav and fatboy.wav on the LAME web page. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] The best lossless encoder
From: "Meister Roger" [EMAIL PROTECTED] I agree (and I still use wShorten) BUT : - Shorten does't seem to be supported/improved any more (last wShorten 2.3a came March 6 1999) - The playlist of wShorten is very poor, and SHN files will be never supported in Winamp or other Free players. On both counts: the source code for shorten 2.3a is freely available. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] General question about MP3
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] [Finding encoder/decoder delays and padding] How does one figure this out? For the delay, encode a wav with the chosen encoder/options, decode it with your usual decoder and compare the processed version to the original. A little guesswork may be required to find the offset, because the processed version will be altered in other ways. For the test signal, try a 1kHz sine wave - unlikely to be altered much, and quite distinctive; you can use (say) the first zero-crossing as your reference point. (It seems to me that this process would be fairly easy to automate, but I don't know of any programs that will do it for you). For the padding, you need to know the length of the original wav. If you don't have that, but the track is known to have been ripped from a CD, I suppose you could make a guess based on CDDA's block size. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] General question about MP3
From: "Paul Hartman" [EMAIL PROTECTED] Somebody pointed out to me that somewhere in the process of encoding a WAV to MP3, then decoding back to WAV some extra frames are added at the end (appears to be silence?). re-encoding and decoding this same thing steadily makes it grow each time. It seems not necessarily to be any particular encoder or decoder, or any specific bitrate. Is there a explaination for this, and is there any way to prevent or correct this (so that a mp3 decoded back to WAV can be as close as possible to the original)? The explanation is twofold: 1) Encoding and decoding delays - of the order of 1000 samples; encoder- and decoder-specific 2) Padding to frame bounaries - on average adds 1152/2 samples The delays add silence to the beginning of the decoded signal; the padding adds silence to the end. If you know the combined (encoder + decoder) delay and the length of the original signal, you can compensate for both effects with a little editing. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] calc_xmin
From: Mathew Hendry [mailto:[EMAIL PROTECTED]] Oh dear, the error reappears if I go from -O to -O2... could be somewhere else now, as calc_xmin looks okay... Now dying in quantize.c/VBR_iteration_loop (I'm testing with lame -v fools.wav). Can anyone pin it down further? -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] calc_xmin
Oh dear, the error reappears if I go from -O to -O2... could be somewhere else now, as calc_xmin looks okay... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] calc_xmin
From: "Mathew Hendry" [EMAIL PROTECTED] ... The values at -8(%ebp) and -16(%ebp) are never initialised. I don't know what the compiler expects to find there. Looking at it again, I think it's trying to load en0 and xmin, but they haven't been initialised yet. Explicitly initialising them to zero doesn't help, though... Here's a quick patch to work around it. (One hack for each loop). ... Better protect all that with #if (defined(__GNUC__) defined(__i386__)) -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mp3 vs. wma
From: "Ross Levis" [EMAIL PROTECTED] there's also no good mp3 DirectMedia codec except for the discontinued FhG pro codec version 1 When you say DirectMedia, do you mean a Windows ACM driver?. If so there are newer versions of the FHG ACM released with some software packages like Nero 4.0 and Cool Edit 2000. They aren't ACM codecs (e.g. they won't show up in Control Panel/Multimedia/Devices). There is a more recent ACM codec around, though. A cracking group called Radium took it upon itself to take the encoder core from Producer Pro and merge it with the official ACM codec. Just a pity they didn't use MP3Enc 3.1 as their base... BTW, QDesign do a rather nice MP2 ACM codec. Under $100, very cheap by their standards... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] using lame363 for shuttle transmission
From: Mark Taylor [mailto:[EMAIL PROTECTED]] Declaring avg_slots_per_frame "volatile" (line 547 in lame.c) fixes it in some cases. I was using the following test options, with fools.wav as my source Delcaring it volatile (what does that do?) or static changes the results for me also (but doesn't fix the problem). This is very strange, since how space for this variable is allocated should not matter at all. More indication of some memory problems. Declaring it volatile causes the compiler to optimise differently (being more careful with the precision of temporaries, stores, etc.), altering the value of frac_SpF, which I believe controls frame padding. Robert sent me this, does anyone know what this instruction means: 0x805e2cc calc_xmin+460: fldl 0xfff0(%ebp) It loads a floating point value from memory into a floating point register. The value in memory is presumably invalid, so the CPU traps when it loads it. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] using lame363 for shuttle transmission
From: Mathew Hendry [mailto:[EMAIL PROTECTED]] The offending function appears to be lame.c/lame_encode(). If I compile this function separately with optimisation disabled the problem disappears. Still looking... Declaring avg_slots_per_frame "volatile" (line 547 in lame.c) fixes it in some cases. I was using the following test options, with fools.wav as my source -b 32 -f -b 128 -f -b 320 -f -b 32 -h -b 128 -h -b 320 -h Where before all were different, now only the 32kbps files are different. With -b 32 -f, even the file sizes are different... I'm using gcc 2.95.2 under WinNT, compiling with the following options -O9 -fomit-frame-pointer -mpentiumpro -ffast-math \ -funroll-loops -Wall -malign-double -mcpu=pentiumpro \ -mfancy-math-387 -pipe and the usual -DNDEBUG -D__NO_MATH_INLINES BTW, can't check the -DABORTFP business, as this gcc doesn't support it (I guess I don't have the right libraries). -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] using lame363 for shuttle transmission
From: Mark Taylor [mailto:[EMAIL PROTECTED]] I just merged his changes back in tonight. Now if I use any optimization, I get the floating point exceptions. Compiling without -DABORTFP will ignore them. But I dont know how they are effecting the output. This error is very frustrating. Has anyone been having these problems on a non-linux platforms? Maybe it is a gcc related bug? The offending function appears to be lame.c/lame_encode(). If I compile this function separately with optimisation disabled the problem disappears. Still looking... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] MSVC fix?
To all those with CVS developer permissions, Has anyone knowingly committed any fixes for the testcase.wav problems that showed up in the MSVC version of LAME? I ask because they seem to have disappeared, and bugs fixed by accident have a tendency to reappear! I do still see small differences between gcc and MSVC versions (maybe 1% of frames are different with --nores) but this can probably be ascribed to floating point code generation and libm differences, and isn't really a worry. On testcase.wav, the two versions now produce identical output. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] LAME in the PRESS
From: Ampex [mailto:[EMAIL PROTECTED]] actually, i believe that the fhg encoder uses joint stereo for anything below 192kbps Depends on which version you use. Anything recent (MP3Enc 3.1 and onwards, IIRC) uses stereo from 160kbps upwards. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] lame -h --nores -V 3 fools.wav fools.mp3
Hi all, Found this while running some performance tests. The above command fails with an assertion failure, or a crash with NDEBUG defined. Any ideas? -V 4 and upwards are fine. D:\Source\lamelame -h --nores -V 3 fools.wav fools.mp3 LAME version 3.62 (www.sulaco.org/mp3) GPSYCHO: GPL psycho-acoustic and noise shaping model version 0.75. Encoding fools.wav to fools.mp3 Encoding as 44.1kHz VBR(q=3) stereo MPEG1 LayerIII qual=2 Frame | CPU/estimated | time/estimated | play/CPU | ETA 60/ 1185( 5%)| 0:00:02/ 0:00:33| 0:00:02/ 0:00:40|0.9521| 0:00:38 Assertion failed: used_bits = bits, file quantize.c, line 419 abnormal program termination -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Portability patches + assertion failure
Hi all, Got a few small patches here to fix warnings and to persuade LAME to compile under MSVC and Cygwin; they mainly handle cases where BRHIST and HAVEGTK are not defined. The files affected are Makefile.MSVC brhist.c get_audio.c lame.c loopold.c machine.h parse.c psymodel.c quantize.c Also, I'm getting an assertion failure in psymodel.c line 658, "partition_s[j] = 0". This affects both MSVC and Cygwin (gcc) versions, so I don't think it's compiler-specific. It happens on testcase.wav, for example, but on all others I've tried too. It seems that partition_s[j] is never being changed from its initial value of -1. --- cvs -q diff (in directory R:\Source\lame\) Index: Makefile.MSVC === RCS file: /cvsroot/lame/lame/Makefile.MSVC,v retrieving revision 1.1.1.1 diff -r1.1.1.1 Makefile.MSVC 8c8 # CC_OPTS = /nologo /Zi --- # CC_OPTS = /nologo /Zi /Ge /GZ 34a35 parse.c \ Index: brhist.c === RCS file: /cvsroot/lame/lame/brhist.c,v retrieving revision 1.1 diff -r1.1 brhist.c 2d1 #include termcap.h 10a10 #include termcap.h Index: get_audio.c === RCS file: /cvsroot/lame/lame/get_audio.c,v retrieving revision 1.18 diff -r1.18 get_audio.c 0a1,3 #ifdef __CYGWIN__ #include io.h #endif Index: lame.c === RCS file: /cvsroot/lame/lame/lame.c,v retrieving revision 1.50 diff -r1.50 lame.c 81a82 #ifdef BRHIST 88c89 --- #endif 520c521 III_psy_ratio *masking; /*LR ratios and MS ratios*/ --- III_psy_ratio (*masking)[2]; /*LR ratios and MS ratios*/ Index: loopold.c === RCS file: /cvsroot/lame/lame/loopold.c,v retrieving revision 1.25 diff -r1.25 loopold.c 182c182,185 int sfb, bits, huff_bits; --- #ifdef HAVEGTK int sfb; #endif int bits, huff_bits; Index: machine.h === RCS file: /cvsroot/lame/lame/machine.h,v retrieving revision 1.7 diff -r1.7 machine.h 78c78 #ifdef _WIN32 --- #if defined _WIN32 !defined __CYGWIN__ Index: parse.c === RCS file: /cvsroot/lame/lame/parse.c,v retrieving revision 1.4 diff -r1.4 parse.c 0a1,3 #ifdef __CYGWIN__ #include io.h #endif Index: psymodel.c === RCS file: /cvsroot/lame/lame/psymodel.c,v retrieving revision 1.31 diff -r1.31 psymodel.c 396c396 fft_short( wsamp_s, energy_s, chn, buffer); --- fft_short( (FLOAT *)wsamp_s, energy_s, chn, buffer); Index: quantize.c === RCS file: /cvsroot/lame/lame/quantize.c,v retrieving revision 1.42 diff -r1.42 quantize.c 577c577,580 int sfb, huff_bits; --- #ifdef HAVEGTK int sfb; #endif int huff_bits; --- Cheers, -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[3]: [MP3 ENCODER] highq mode
From: "Greg Maxwell" [EMAIL PROTECTED] Can windows users redirect stderr like us poor saps stuck using Free Software? 9x users can't. NT users can; and the NT console has scrollback anyway. I'm currently running a triple boot system (Linux, Win98, Win2k). I might be tempted to switch to Linux as my default boot if so many of my favourite toys weren't Windows-based. ;) BTW, the Linux distribution I have (Mandrake 6.x) uses pgcc (a Pentium-specific branch of gcc) as its default compiler. Gives a noticable speed improvement for LAME, and I haven't noticed any glitches with it. Since pgcc was apparently used to build the entire Mandrake distribution, I guess it's a pretty stable compiler now... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] VBR play time
From: Osamu Shigematsu [mailto:[EMAIL PROTECTED]] Hello everyone. Is there way to know VBR mp3 play time quickly? If a VBR header is present, use that. Otherwise, count the frames. (A VBR header will give incorrect results if the MP3 has been truncated, so if you want a reliable result, you'll have to count the frames anyway). -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] To use VBR or not not use?
From: Meister [mailto:[EMAIL PROTECTED]] Which are the best MP2 encorders ??? (at 320 kb/s) Q-Design i-Media and Philips Power Library seem both to be highly regarded. MP2 supports bitrates up to 384kbps, BTW. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] the new fraunhofer codec
From: Ampex [mailto:[EMAIL PROTECTED]] how is the quality of the new fhg codec, the one included in musicmatch jukebox, cool edit 2000 and nero? encoding time is very very slow at highest quality, is this any indication of a higher quality encode taking place, or simply bad programming? has anyone done any benchmarks of the codec as compared to lame/mp3enc? I found the quality of this new codec disappointing. Although, bitrate for bitrate, it appears to reduce overall noise and improve frequency response, it produced very annoying high frequency artifacts on a lot of the material I tested, even at high bitrates. Overall, I think MP3Enc 3.1 sounds better. YMMV. As for speed, FhG have never been the world leaders in that area. mp3enc -qual 9 isn't much faster. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] ATTN: Mark Taylor
Mark, I sent some feedback to you regarding the testcase.mp3 failures with MSVC (results from that debug code you added). Did you receive those two messages in the end? The first attempt (sent on Wednesday sometime) bounced back at me after two days, but I tried sending them again today... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MP3 sampling and bit rates
From: "Mark Taylor" [EMAIL PROTECTED] From: "Mathew Hendry" [EMAIL PROTECTED] Looking at the sampling rate options in FhG's MP3 plugin for Cool Edit Pro, some odd sampling / bitrate choices are offered. Bitrates: 18kbps, 20kbps Sampling rates: 11025Hz, 12000Hz This might be part of MPEG2.5? I believe FhG developed it, but it never became an official ISO standard. But I think most players support it because it is part of the demonstation decoding source? Yep. A little more scouring reveals that MPEG 2.5 vs. MPEG 2 is like MPEG 2 vs. MPEG 1 - halved sampling rates and mostly-halved bitrates. But the 8kHz sampling rate is not listed by the plugin, and neither are some of the bitrates (e.g. 4kbps). Perhaps most useful for very low bitrate voice material? -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Quantization questions
Hi all, Woke up this morning with a few questions... When comparing different quantizations, does LAME (explicitly or implicitly) weight audible noise (noise above threshold) according to the "psychoacoustic importance" of the individual scalefactor bands? Are there any empirical figures available for the "annoyance level" of noise in different bands? What about special cases of noise such as filtering? Can annoyance be masked by greater annoyance in another band? -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] first attempt at a validation procedure
From: Mark Taylor [mailto:[EMAIL PROTECTED]] I've put this new mp3 on sulaco for inspection. /incoming/testcase.new.mp3 -- Mat. I just took a look: The first difference I could see is frame 4. Blocktypes and modes are all the same, you have the first scalefac=0, and my version has it nonzero. Kind of suspicious that it is the first scalefactor - could be some kind of buffer overflow problem :-( I dont think it could be due to roundoff error differences. Another quirk: towards the end of the file, from offsets 0x0b0f to 0x0b5a, the two files appear to contain the same data, but offset by one byte from one another. offset : testcase.mp3 | testcase.new.mp3 0x0b0f : 0x93 | 0xb8 0x0b10 : 0x1f | 0x93 0x0b11 : 0x5b | 0x1f 0x0b12 : 0x59 | 0x5b and so on. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mp3enc31 linux
From: "Ampex" [EMAIL PROTECTED] does anyone have the full version of this encoder, or know where it is available? the windows version is rather easy to find, but the linux version doesnt seem to be "out there". any feedback appreciated... You could run the Windows version under Linux with WINE or similar, I guess. I'm not sure what sort of performance hit that imposes, though... On a related note - does anyone know of a patch to make mp3enc 3.1 work on NT 4.0 SP3+? It dies almost immediately at bitrates above 128kbps on such systems (might be related to stereo mode). I've seen other patches - e.g. to adjust stereo modes and fix the -sti option - but nothing for this bug... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] first attempt at a validation procedure
From: "Mark Taylor" [EMAIL PROTECTED] I would be interested if others using CVS could post the results from 'make test'. Especially non-linux users, although I dont know what the 'wc' command would be under windows. fc /b file1 file2 But ouch! Under Win32/MSVC not only are the files different in almost every byte, but of different sizes! testcase.new.mp3 is 2926 bytes, compared with your 2935 bytes. I'll upload the mp3 to sulaco for anyone who wants to take a look. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] first attempt at a validation procedure
From: "Mathew Hendry" [EMAIL PROTECTED] From: "Mark Taylor" I would be interested if others using CVS could post the results from 'make test'. Especially non-linux users, although I dont know what the 'wc' command would be under windows. fc /b file1 file2 But ouch! Under Win32/MSVC not only are the files different in almost every byte, but of different sizes! testcase.new.mp3 is 2926 bytes, compared with your 2935 bytes. I'll upload the mp3 to sulaco for anyone who wants to take a look. Oops, not quite as bad as I thought. WinCvs was performing newline conversions/keyword substitutions on the files. Were they added as binary files? I used cvs update -kb file to get them manually in the end. So now the files are the same size. No differences in the first half of the mp3, then plenty afterwards (from offset 0x68f). Should there be switch in stereo mode or block type or something about half way through? I don't have mp3x to look at the files closely. I've put this new mp3 on sulaco for inspection. /incoming/testcase.new.mp3 -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] splitting Mp3
From: "Cem Alacayir" [EMAIL PROTECTED] Does anyone have an idea how to split the mp3 in to parts? But I don't mean I want to have new mp3 files I only need the parts. For example, if I split a mp3 into 3 parts , the parts should be continuos , I mean I should be able to play the parts in sequence (with a special player) and get the same result as playing the whole original mp3 how is it possible? I need your help If you're using a special player, I guess you can split it in any way you want. There are plenty of file splitting utilities around; one I remember from years back is called "sploin"; portable C source for it should be easily available. All the "special player" would have to do is read the files in sequence, providing a continuous stream to the decoder. Assuming you have a self-contained decoder implementation (e.g. mpg123) this doesn't require you to know anything about the structure of MP3 files: simply treat them as binary data and join them together. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] --Strange pop at beginning of song
From: Doug Wood [mailto:[EMAIL PROTECTED]] Another problem I have noticed in the CD ripping process is that the time values in the directory of the CD are often not accurate. I have tried different rippers and have written my own ripper and they all have identical problems in picking up the beginning of a song when asked to start at the beginning of a track on some CD's. This is usually down to problems with the CD-ROM drive, which will usually return data from a position on the CD slightly offset from the requested position. Most CD rippers have an option to compensate for this, but EAC (http://www.exactaudiocopy.de) is the only one I know of that offers a reasonably easy way to calculate it - based on a database of particular pressings of fairly common CDs. If you have a CD recorder, it is possible to compensate for the offsets in the reader and writer, and therefore quite possible to produce exact duplicates of audio CDs. Plextor drives seem to be preferred for good quality ripping/copying. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Windows Binaries
From: Pierre Darbon et Hurgon J.Sebastien [mailto:[EMAIL PROTECTED]] I'm a newbie, and I wonder how the Windows binary found in the Russian site (http://www.chat.ru/~dkutsanov/index.htm) was compiled. I supposed it's done with Microsoft Visual C I think so. , but I want to know if it is optimized for i586, i686 or anything else. I don't own MSVC myself, so I can't understand the parameters in the Makefile. If it's been built using the MSVC Makefile, it will be optimised for P6 (Pentium Pro or Pentium II). I think the workspace/project files (for building within the MSVC IDE) use the same setting (/G6). I'm personnally using the CygWin package (Freeware, http://sourceware.cygnus.com/cygwin/) to compile the Lame sources, but even with the i686 tweaks (I have a good old PentiumPro), it's slower than the Russian binary (Well, it's 3-4% slower, not too bad...) There are some optimisations in the MSVC version not present in the gcc/iX86 version - namely the full assembly implementation of quantize_xrpow[_ISO] in quantize-pvt.c. On top of that, MSVC is very good with floating point code, better than gcc and (I think) better even than Intel's reference compiler. pgcc (a custom version of gcc for Pentium CPUs) might fare better if you can find/build it for Windows. pgcc is the default compiler on my "experimental" Linux system (Mandrake 6.something) and does seem to improve speed a little over regular gcc. and a lot, lot bigger (But with today's drives, who cares...) You probably only need to strip the debug info out of the executable. Try "strip lame.exe" after compiling. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Debug info left in FhG coder
Hi all, Here are some strings that are left in plain-text form in the Nero (demo) version of the FhG codec. Thought some of them (e.g. the chaos (atonality?) method and spreading function descriptions) might be of interest. maxBitSp_s bitres tuning: maxBitSpend short block minBitSp_s bitres tuning: minBitSpend short block peMax_s bitres tuning: pe Max short block peMin_s bitres tuning: pe Min short block rpre_s Preecho control ratio (short blocks) rpmin_s maximum preecho control impact (short blocks) TONE_COMB_LIMIT_FREQ_S Frequency limit for which peak filter chaos method is calculated (only relevant for -CHAOS_METHOD_S 4) CHAOS_METHOD_S chaos method for short blocks short block chaos method 0: euclidic dist., 1: fast euclidic dist., 2: peak filter, 3: fast peak filter, 4: combination of 0 and 2 CB_MODE_S Number of sfb's where min. threshold is used in adapt (short) maskNoHole_S no hole in spreading function for short blocks TMN_S Tone masking noise for short blocks NMT_S Noise masking tone for short blocks maxBitSpbitres tuning: maxBitSpend long block minBitSpbitres tuning: minBitSpend long block peMaxbitres tuning: pe Max long block peMinbitres tuning: pe Min long block rpre Preecho control ratio (long blocks) rpmin maximum preecho control impact (long blocks) TONE_COMB_LIMIT_FREQ Frequency limit for which peak filter chaos method is calculated (only relevant for -CHAOS_METHOD 4) CHAOS_METHOD chaos method for long blocks long block chaos method 0: euclidic dist., 1: fast euclidic dist., 2: peak filter, 3: fast peak filter, 4: combination of 0 and 2 CB_MODE Number of sfb's where min. threshold is used in adapt (long) TONE_LIMIT_FREQ Frequency limit for which tonality is computed maskNoHole no hole in spreading function for long blocks disable the suspension hole in the spreading function maskhighslope of spreading function for high frequencies masklowslope of spreading function for low frequencies TMN Tone masking noise for long blocks NMT Noise masking tone for long blocks -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --Newbie Question (wheres the source) and a cool logo
From: "David" [EMAIL PROTECTED] -Where do I get the latest source? I have seen the source for 3.51 but not any of the beta.. Betas (up to 3.59 last I looked) are on the download page at http://www.sulaco.org/mp3 . Look for "Newer Beta Versions". Since you appear to be using Windows, I think you'll need the patch I posted yesterday (Subject: MSVC fix) to make 3.59 work. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] MSVC fix
Hi Mark, A recent change somewhere has caused a collision between the BOOL #define in mpglib.h and a typedef in one of the Windows header files. Suggested fix: diff -r1.1.1.1 mpglib.h 32a33,35 #if ( defined(_MSC_VER) || defined(__BORLANDC__) ) typedef int BOOL; /* windef.h contains the same definition */ #else 33a37 #endif -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] MP3 sampling and bit rates
Hi all, Looking at the sampling rate options in FhG's MP3 plugin for Cool Edit Pro, some odd sampling / bitrate choices are offered. Bitrates: 18kbps, 20kbps Sampling rates: 11025Hz, 12000Hz According to the rate listings produced by LAME and my knowledge, none of these are valid for MPEG 1 or 2. Some sort of FhG extension, or an oversight in the LAME tables? BTW, the overall quality of this plugin is disappointing - it produces high frequency "twinkling" artifacts on a lot of material even at high bitrates (I was testing mainly at 192kbps, where I would usually expect transparency). However, they are faint, and may be a deliberate compromise to gain quality somewhere else - I very much doubt the people at FhG didn't detect them. The same problem afflicts the FhG codecs in MusicMatch and Nero. Whatever their reasons, MP3Enc 3.1 is still the best IMO. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Problem in porting MPG123
From: "Paul F. Johnson" [EMAIL PROTECTED] Also, does anyone know where mmap() is? I can't find it in the current distribution? mmap is a Unix (Posix?) system call, for mapping a file into memory. If mpg123 uses it, and RISC OS doesn't have something equivalent, porting could be tricky... It may not be that tricky - it would depend on how the file was aligned in memory, would it be word or byte (i.e. 4 or 8 bytes) aligned? Probably more like several kilobytes, matching the local MMU page alignment. Faking a more strict alignment isn't difficult, though - allocate a larger buffer (data size + alignment - 1) and offset your data within it (base address % alignment). RISC OS uses word alignment when we load a file into memory, though mapping a file into memory is something else! Indeed, particularly if code used on memory-mapped files is also used on normal memory-resident data... small files (modulo available swap) can of course be fully loaded into memory, so they're no problem. For large files you could well be stuck... Whether any of this is a big problem really depends on where and why mmap() is being used. Do you know enough about the source to work that out? The only source release of mpg123 I have is the modified version used in LAME, and it doesn't use mmap() at all... -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Problem in porting MPG123
From: "Mathew Hendry" [EMAIL PROTECTED] Faking a more strict alignment isn't difficult, though - allocate a larger buffer (data size + alignment - 1) and offset your data within it (base address % alignment). Make that allocation_size = data_size + alignment - 1; modulo = base_address % alignment; aligned_address = base_address + (modulo != 0 ? alignment - modulo : 0); -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Using libm or not
From: "Gabriel Bouvigne" [EMAIL PROTECTED] Perhaps a stupid question, but what is libm ? The maths library in C compilers in the style of Unix cc. It contains the math.h functions; some compilers don't link with it by default. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re: [MP3 ENCODER] profiling
From: "michael cheng" [EMAIL PROTECTED]
-fno-inline. It's all in the info file (and unlike most stuff in info,
this
is
easy to find :-).
But I want *everything else* inlined (if possible), except this one
function.
I don't know of any neat way around this (there's no "noinline" keyword or
attribute, for example) but you can hack up something like
/* foo.h */
...
/* int func(void) */
extern int (*const volatile func)(void); /* replace original declaration */
...
/* foo.c */
...
int func_renamed(void) { /* rename original function */
return 0;
}
int (*const volatile func)(void) = func_renamed; /* indirect calls through
this pointer */
...
then call func() to get the non-inlined version. It's even portable. ;)
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] mp3enc vs. acm codecs
From: Ampex [mailto:[EMAIL PROTECTED]] is the command-line driven mp3enc better than the fhg acm codecs, such as in producer pro, and producer pro 2? Same encoding engine, AFAIK. They do provide different sets of options, though. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Quick countbits optimisation
From: Mark Taylor [mailto:[EMAIL PROTECTED]] Does this give any speed improvement? It is beginning to get rather complicated for what I'm guessing is very little gain? It speeds up inner_loop by 25%, and bin_search_StepSize2 by 20%. Overall speedup is about 5% - maybe not significant... As for complicated, the version I'm using now is a little tidier. ;) I did add your code for adj43asm, which lead me to the following: Since ix = 8191+15 = 8206, pow43, adj43 and adj43asm need to be dimensioned from 0..8206, so PRECALC_SIZE should be 8207, not 8206? Yes, I think you're right. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Quick countbits optimisation
From: Mathew Hendry [mailto:[EMAIL PROTECTED]]
From: "Takehiro Tominaga" [EMAIL PROTECTED]
so if you want to change,
diff -r1.2 takehiro.c
540c540
{
---
if (highq) {
you should changed to make ix range check in choose_table().
And choose_table_short, I suppose. Something like
[...]
Can improve hq mode speed a bit as well. The bounds check within count_bits
can be removed entirely with this patch to quantize-pvt.c and takehiro.c.
Any obvious problems?
In quantize-pvt.c I've also adjusted iteration_init to use the pow43 lookup
table to generate adj43asm. Should be a bit faster, and fixes a bug which
would leave the last entry in the array uninitialised.
diff -r1.11 quantize-pvt.c
133,137c133,135
adj43asm[0]=0.0;
for (i = 1; i PRECALC_SIZE - 1; i++)
adj43asm[i] = i -.5 - pow(0.5 * (pow((double)(i - 1), 4.0/3.0)
+ pow((double)i,4.0/3.0)), 0.75);
---
adj43asm[0] = 0.0;
for (i = 1; i PRECALC_SIZE; i++)
adj43asm[i] = i - 0.5 - pow(0.5 * (pow43[i - 1] + pow43[i]),
0.75);
376a375
FLOAT8 xrp_max;
378a378,390
if (highq) {
int i;
const FLOAT8 *xrp = xrpow;
xrp_max = 0;
for (i = 576 / 4; i 0; --i, xrp += 4) {
if (xrp[0] xrp_max) xrp_max = xrp[0];
if (xrp[1] xrp_max) xrp_max = xrp[1];
if (xrp[2] xrp_max) xrp_max = xrp[2];
if (xrp[3] xrp_max) xrp_max = xrp[3];
}
}
381,382c393,398
cod_info-quantizerStepSize += 1.0;
bits = count_bits(l3_enc[gr][ch], xrpow, cod_info);
---
cod_info-quantizerStepSize += 1.0;
if (highq xrp_max * pow(2.0, cod_info-quantizerStepSize *
-0.1875) = PRECALC_SIZE - 0.5) {
bits = 10;
} else {
bits = count_bits(l3_enc[gr][ch], xrpow, cod_info);
}
982a999,1012
FLOAT8 xrp_max;
if (highq) {
int i;
const FLOAT8 *xrp = xrspow;
xrp_max = 0;
for (i = 576 / 4; i 0; --i, xrp += 4) {
if (xrp[0] xrp_max) xrp_max = xrp[0];
if (xrp[1] xrp_max) xrp_max = xrp[1];
if (xrp[2] xrp_max) xrp_max = xrp[2];
if (xrp[3] xrp_max) xrp_max = xrp[3];
}
}
986c1016,1020
nBits = count_bits(ix, xrspow, cod_info);
---
if (highq xrp_max * pow(2.0, cod_info-quantizerStepSize *
-0.1875) = PRECALC_SIZE - 0.5) {
nBits = 10;
} else {
nBits = count_bits(ix, xrspow, cod_info);
}
diff -r1.3 takehiro.c
549a550,551
/*
556a559,560
*/
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CVS update access and changes to make current C VS version compile
From: "Mark Taylor" [EMAIL PROTECTED] XRPOW_FTOI(x, rx); should be XRPOW_FTOI(x-.5, rx); ? No, it is right. But Acy missed to fix adj43asm initialization. details are in my old mail on this ML. ok, fixed. But does the MSVC asm code want the new adj43asm[], or the old adj43asm[]? The new one. Here's the full set /* for other than gcc/i383 and MSVC */ for (i = 0; i PRECALC_SIZE - 1; i++) adj43[i] = (i + 1) - pow(0.5 * (pow43[i] + pow43[i + 1]), 0.75); adj43[i] = 0.5; /* for gcc/i386 and MSVC */ adj43asm[0] = 0.0; for (i = 1; i PRECALC_SIZE; i++) adj43asm[i] = i - 0.5 - pow(0.5 * (pow43[i - 1] + pow43[i]), 0.75); -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: Re[2]: [MP3 ENCODER] CVS update access and changes to make current C VS version compile
From: Holger Dors [mailto:[EMAIL PROTECTED]] [...] but it breaks my validation tests. speaking of validation: is there any simple test available that a (Win32) user can check that his version of Lame is working as supposed? I think the best you can do at the moment is disable any system-specific optimisations and force it to use the "generic" versions of the functions. e.g. you may see #ifdef _MSC_VER /* ... MSVC-specific code ... */ #else /* ... generic code ... */ #endif which you can temporarily change to /*#ifdef _MSC_VER*/ #if 0 /* ... MSVC-specific code ... */ #else /* ... generic code ... */ #endif (obviously BCB will use different #defines, but I don't know them :) Then compare mp3s produced by this with those produced by a system-specific version. I use fc.exe, which I think is supplied as standard with Windows fc /b generic.mp3 modified.mp3 When making changes to quantize_xrpow, I've been running tests like this, and the current (per CVS) version produces identical results across versions under MSVC. I tested "generic" (pure C), "partial asm" (asm only for XRPOW_FTOI) and "full asm" (Acy's code with modifications) implementations, both normal (quantize_xrpow_ISO) and high quality (quantize_xrpow). I find this quite important as there's no "offical" release, and I found that the files created with a LAME version I downloaded weren't bit compatible with a version I compiled using BCB. Shouldn't this be the case? I think there have been several changes since 3.57 that will change output. The new -h quantization, for one. Some reference mp3s on sulaco.org, updated periodically, would be handy for keeping track of this. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Quick countbits optimisation
From: "Takehiro Tominaga" [EMAIL PROTECTED]
so if you want to change,
diff -r1.2 takehiro.c
540c540
{
---
if (highq) {
you should changed to make ix range check in choose_table().
And choose_table_short, I suppose. Something like
diff -r1.2 takehiro.c
306a307,311
if (max 8191 + 15) {
*s = 10;
return -1;
}
378a384,388
if (max 8191 + 15) {
*s = 10;
return -1;
}
540c550
{
---
if (highq) {
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] CVS update access and changes to make current CVS version compile
From: Takehiro Tominaga [mailto:[EMAIL PROTECTED]] before check in new quantize routine, see this hint and make faster one :p table making. adj43[0] = 0.0; for (i = 1; i PRECALC_SIZE; i++) adj43[i] = i - 0.5 - pow(0.5 * (pow((double)(i - 1), 4.0/3.0) + pow((double)i, 4.0/3.0)), 0.75); Better make that adj43asm[...], or it will break the non-asm versions. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] fhg encoder
From: Ampex [mailto:[EMAIL PROTECTED]] why does the fhg encoder, even at 256kbits/sec seem to not like going above 16KHz? Because lower frequencies are usually much more significant. Can you hear the difference? That's all that matters... The only time I've noticed FhG fail at 256kbps is with castanets.wav, where there is still some faint pre-echo. This may be a limitation of the format, rather than the encoder; MP2 has better time resolution and seems to perform better. (Tested using the QDesign codec). With LAME @ 256kbps the pre-echo is noticably worse, but still faint. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] CVS update access and changes to make current C VS version compile
From: Mathew Hendry [mailto:[EMAIL PROTECTED]]
From: Takehiro Tominaga [mailto:[EMAIL PROTECTED]]
before check in new quantize routine, see this hint and make
faster one :p
table making.
adj43[0] = 0.0;
for (i = 1; i PRECALC_SIZE; i++)
adj43[i] = i - 0.5 - pow(0.5 * (pow((double)(i - 1), 4.0/3.0)
+ pow((double)i,
4.0/3.0)), 0.75);
Better make that adj43asm[...], or it will break the non-asm versions.
Works quite nicely. Try this quantize_xrpow with a modified adj43asm
/*
Timings for the MSVC asm version, before and after, testing "fools.wav"
Func Func+Child Hit
Time % Time % Count Function
-
860.617 6.2 860.617 6.284439 _quantize_xrpow
789.424 5.7 789.424 5.784439 _quantize_xrpow
*/
void quantize_xrpow(FLOAT8 xr[576], int ix[576], gr_info *cod_info) {
/* quantize on xr^(3/4) instead of xr */
const FLOAT8 quantizerStepSize = cod_info-quantizerStepSize;
const FLOAT8 istep = pow(2.0, quantizerStepSize * -0.1875);
#ifndef _MSC_VER
{
FLOAT8 x;
int j, rx;
for (j = 576 / 4; j 0; --j) {
x = *xr++ * istep;
XRPOW_FTOI(x, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *ix++);
x = *xr++ * istep;
XRPOW_FTOI(x, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *ix++);
x = *xr++ * istep;
XRPOW_FTOI(x, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *ix++);
x = *xr++ * istep;
XRPOW_FTOI(x, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *ix++);
}
}
#else
/* def _MSC_VER */
{
/* asm from Acy Stapp [EMAIL PROTECTED] */
int rx[4];
_asm {
fld qword ptr [istep]
mov esi, dword ptr [xr]
lea edi, dword ptr [adj43asm]
mov edx, dword ptr [ix]
mov ecx, 576/4
} loop1: _asm {
fld qword ptr [esi] // 0
fld qword ptr [esi+8] // 1 0
fld qword ptr [esi+16] // 2 1 0
fld qword ptr [esi+24] // 3 2 1 0
fxch st(3) // 0 2 1 3
fmul st(0), st(4)
fxch st(2) // 1 2 0 3
fmul st(0), st(4)
fxch st(1) // 2 1 0 3
fmul st(0), st(4)
fxch st(3) // 3 1 0 2
fmul st(0), st(4)
add esi, 32
add edx, 16
fxch st(2) // 0 1 3 2
fist dword ptr [rx]
fxch st(1) // 1 0 3 2
fist dword ptr [rx+4]
fxch st(3) // 2 0 3 1
fist dword ptr [rx+8]
fxch st(2) // 3 0 2 1
fist dword ptr [rx+12]
dec ecx
mov eax, dword ptr [rx]
mov ebx, dword ptr [rx+4]
fxch st(1) // 0 3 2 1
fadd qword ptr [edi+eax*8]
fxch st(3) // 1 3 2 0
fadd qword ptr [edi+ebx*8]
mov eax, dword ptr [rx+8]
mov ebx, dword ptr [rx+12]
fxch st(2) // 2 3 1 0
fadd qword ptr [edi+eax*8]
fxch st(1) // 3 2 1 0
fadd qword ptr [edi+ebx*8]
fxch st(3) // 0 2 1 3
fistp dword ptr [edx-16]// 2 1 3
fxch st(1) // 1 2 3
fistp dword ptr [edx-12]// 2 3
fistp dword ptr [edx-8] // 3
fistp dword ptr [edx-4]
jnz loop1
mov dword ptr [xr], esi
mov dword ptr [ix], edx
fstp st(0)
}
}
#endif
}
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] quantize_xrpow: merging recent changes
Hi all, I've merged Acy's, Takehiro's and my recent changes to quantize_xrpow[_ISO], resulting in a tidier version (attached). With Takehiro's changes, we can eliminate the short block case entirely, so the functions are much shorter and faster. And with Acy's changes, we have a super-speedy MSVC version (with gcc/i386 version to follow?). With my compareval0 addition for non-ISO mode, we get another small speedup to the C version. Manual loop unrolling of the C version helps quite a lot as well, but I've left that out to keep things simple. Some speed results (Celeron 400, Win98SE), each version run 3 times Standard mode: lame_stdiron.wav nul 1.9520, 2.0136, 2.0010 lame_cv0iron.wav nul 2.0323, 2.0010, 2.0253 lame_acyiron.wav nul 2.5422, 2.5331, 2.5221 (compareval0 doesn't really help in ISO mode) High quality mode: lame_std -h iron.wav nul 1.3081, 1.3028, 1.3052 lame_cv0 -h iron.wav nul 1.3437, 1.3494, 1.3557 lame_acy -h iron.wav nul 2.1416, 2.1416, 2.1574 -- Mat. quantize-pvt_update.c
RE: [MP3 ENCODER] www.mp3tech.org
From: Jason Antony [mailto:[EMAIL PROTECTED]] -- How do I compile the source code to create the executable using Borland C++ 5.02? Any pointers would be great! ; ) [all I know about C++ j/k] I don't know BC++, but I guess you should be able to get it working by tweaking Makefile.MSVC a bit. -- Failing that, where can I get a win32 executable of Lame 3.57 and not 3.54? As mentioned on sulaco.org http://www.chat.ru/~dkutsanov/~index.htm -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] new ass-kicking quantize-pvt.c
From: "Stapp, Acy" [EMAIL PROTECTED] This is the new ass-kicking quantize-pvt.c with inline assembly for MSVC. Nice! With "lame -h iron.wav nul" on my Celery 400 I get (after merging with Takehiro's latest changes too) XRPOW_FTOI: 1.36x XRPOW_FTOI + compareval0: 1.71x Acy's new code: 2.03x BTW, I noticed while profiling the other day that in normal mode, quantize_xrpow is usually called *more* often than in HQ mode. What's up with that? -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Optimization
From: "Acy Stapp" [EMAIL PROTECTED] I unfortunately can't get VTune to work reliably on LAME. If someone wants to point me toward any other math-intensive inner loops I will be glad to optimize those as well. The other big one is the FFT code; always shows up near the top of profiles. But there are quite a few high performance FFT implementations around (e.g. FFTW) that we haven't tried yet. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] fhg mp3enc vs. lame at high bitrates
From: "Mark Stephens" [EMAIL PROTECTED] this really can't be answered except by you. The best quality you can achieve is WAV files. For MP3's, IMHO, at 320kbps you can just about use any decent encoder and not hear a difference. LAME would be fine for this, and much faster than mp3enc. Xing, using audio catalyst 2.1, would be fine and the quickest. I don't think I'd recommend Xing for this. It doesn't get near transparency on some test tracks (e.g. fatboy.wav). And in some cases, it actually sounds *worse* at 320kbps than it does at 128kbps. :/ -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] CVS and Win32
From: Gabriel Bouvigne [mailto:[EMAIL PROTECTED]] Anyone has some experience with cvs and win32? A few hours of experience (installed it last night ;) Where to find it? http://www.wincvs.org -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Two quick MSVC patches + more quantize_xrpow
Hi all,
The second path is a simple syntax error, the first is rather odd -
commenting out the preemphasis block causes the encoder to stick in the
outer loop on my small test track, even though preemphasis is not enabled -
!(notdone[0] || notdone[1]) never becomes true. This only happens with
optimisation switched on - something uninitialised somewhere?
=
diff -r1.1.1.1 loopold.c
443d442
/*
450d448
*/
=
diff -r1.5 quantize-pvt.c
860c860
temp0 = 0.0946;
---
FLOAT8 temp0 = 0.0946;
=
Acy's (hey, at least two EAers on the list now ;) full asm long block
implementation gives 2.2x speed vs. 2.1x for the old version. We might see
larger gains on the new (and more complex) non-linear quantization routines,
so maybe a gcc version is worthwhile.
Acy's code owes its speed partly to manual loop unrolling. This is easy
enough to do in C with the new quantize_xrpow - try this for the long block
inner loop
for (j=576/4;j0;j--) { /* 4x manual unroll */
x = istep_l * *xr++;
XRPOW_FTOI(x-.5, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *(ix++));
x = istep_l * *xr++;
XRPOW_FTOI(x-.5, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *(ix++));
x = istep_l * *xr++;
XRPOW_FTOI(x-.5, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *(ix++));
x = istep_l * *xr++;
XRPOW_FTOI(x-.5, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *(ix++));
}
I get 1.39x with this vs. 1.25x with the previous version.
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] More segfaults with 3.56
From: "Robert Hegemann" [EMAIL PROTECTED]
lame -v fatboy.wav
for (j=192;j0;j--)
{
x = istep0 * *xr++;
/* *(ix++) = (int)( x + adj43[(int)x]); */
XRPOW_FTOI(x-.5, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *(ix++));
x = istep1 * *xr++;
/* *(ix++) = (int)( x + adj43[(int)x]); */
XRPOW_FTOI(x-.5, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *(ix++));
x = istep2 * *xr++;
/* *(ix++) = (int)( x + adj43[(int)x]); */
XRPOW_FTOI(x-.5, rx);
XRPOW_FTOI(x + QUANTFAC(rx), *(ix++));
Crashes here for me. rx == 62312, which is way out of bounds according to
quantize-pvt.h
#define PRECALC_SIZE 8206 /* 8191+15. should never be outside this. see
count_bits() */
Do we need to drop the table-based approach here - the values of *xr seem to
be rather large for short blocks...
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
