Re: [mp3encoder] decoding, how many chunks of main info?
From: Torsten Mohr [EMAIL PROTECTED] Subject: [mp3encoder] decoding, how many chunks of main info? Date: Sun, 4 Feb 2007 18:08:18 +0100 reading in the ISO 11172-3 i see on page 43, Figure A.7.b. that the MP3 stream consists of frames (of course) and that a part of the main data can be located in a previous frame. That is ok so far, but in the example i see also that the main data can span _several_ previous frames. Is there a limitation to the number of previous frames that i need to consider for the main data of a frame? For example, i'm decoding frame 345, it is ok that i need to look back to frame 344 in some cases. As i understand Figure A.7.b i also may need to consider frame 343. How far can this reach back? Is this something that is just on paper but does not happen in reality? Why don't you test by yourself :p ? It happens every mp3 files. The max number of buffered frames is 255, IIRC. It can be determined by some easy calculation. The blow comments are cited from 'libmp3lame/encoder.h' in the LAME source. /* mpeg1: buffer=511 bytes smallest frame: 96-38(sideinfo)=58 * max number of frames in reservoir: 8 * mpeg2: buffer=255 bytes. smallest frame: 24-23bytes=1 * with VBR, if you are encoding all silence, it is possible to * have 8kbs/24khz frames with 1byte of data each, which means we need * to buffer up to 255 headers! */ /* also, max_header_buf has to be a power of two */ How does this interfere with resyncing? If i need to resync to a frame and i find a valid frame, but its main data starts in the 4th previous frame, then i have to skip this valid frame, is this correct? Right. In the worst case, you need to skip 255 frames. Can anybody suggest me a pseudo-algorithm that considers both problems (resyncing back-referring of main data)? Sorry, I've ever wrote an mp3 decoder and I cannot show you. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] bug in id3v2 ??
Hi, i'm using LAME 3.98 under WinXP EN SP2 and it crashes when i use ID3v2 genre higher than 9. The folowing examples differs only in genre tag '--tg'. Confirmed. type lame --tg 14 --id3v2-only in.wav out.mp3 and it happened. This should be bug. I will open the bug report on sf.net. Thank you for your valueable bug report. Is it possible to have track number as a string, i.e. 01 is 01 and NOT just 1 ? Sorry, but this is not possible with current LAME (version 3.xx). On experimental branch, it is possible. I hope someday it is possible for everyone. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Compiling lame with Sun Studio 10
From: Moinak Ghosh [EMAIL PROTECTED] Subject: [mp3encoder] Compiling lame with Sun Studio 10 Date: Fri, 18 Nov 2005 07:28:04 -0800 (PST) I had been able to compile lame 3.96.1 using the Sun Studio 10 compiler on Solaris 10 x86. Except for a small change I had to make everything went fine. The diffs are below: Thanx. fixed in CVS. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Cannot Compile on MS VC++ 2005 Beta 2
From: Gabriel Bouvigne [EMAIL PROTECTED] Subject: Re: [mp3encoder] Cannot Compile on MS VC++ 2005 Beta 2 Date: Wed, 14 Sep 2005 20:30:19 +0200 It is likely that you are compiling the ACM or DirectShow interfaces. Both are requiring windows.h However, lame.exe or libmp3lame are not requiring it. I think it is requred to compile lame.exe. There're following code in libmp3lame/machine.h #if ( defined(_MSC_VER) || defined(__BORLANDC__) || defined(__MINGW32__) ) # define WIN32_LEAN_AND_MEAN # include windows.h # include float.h # define FLOAT_MAX FLT_MAX #else machine.h is always used when compiling libmp3lame and lame.exe. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Cannot Compile on MS VC++ 2005 Beta 2
From: Travis McMurry [EMAIL PROTECTED] Subject: [mp3encoder] Cannot Compile on MS VC++ 2005 Beta 2 Date: Tue, 13 Sep 2005 20:32:02 -0700 (PDT) It keeps on buggin' about a 'windows.h' file not present in the includes. I did a search of all the lame source code checked out tonight via cvs and there was no file called 'windows.h' At least with VC6, the file is provided by C compiler. So it is included by #include windows.h, not by #include windows.h I have no VC++ 2005 and I cannot test it, but I wonder windows.h is really needed on such compiler. What will happedn when you remove the include statement and compile it ? -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Warning: corrupt or unsupported WAVE format
From: Rishi [EMAIL PROTECTED] Subject: [mp3encoder] Warning: corrupt or unsupported WAVE format Date: Sat, 13 Aug 2005 11:29:12 +0530 --- rec02.wav: RIFF (little-endian) data, WAVE audio, IMA ADPCM, mono 8000 Hz --- When I run lame to convert it into MP3 it gives this error and proceeds. --- Warning: corrupt or unsupported WAVE format Assuming raw pcm input file LAME version 3.96.1 (http://lame.sourceforge.net/) --- The converted mp3 file that is created has a hiss. :-( Any ideas what I can do to get lame to recognize this audio file format so that it can convert the wave file to mp3? Use libsndfile enabled lame. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Leading Zeros
From: Musicman [EMAIL PROTECTED] Subject: [mp3encoder] Leading Zeros Date: Sun, 26 Jun 2005 21:23:53 +0200 It's not possible to create LAME mp3s that have an id3v2 tag with a track number like this: 05 LAME doesn't support leading zeros. As I wrote in RFE (formely as bug report) on sf.net, this is the spec of current LAME. http://sourceforge.net/tracker/index.php?func=detailaid=1225324group_id=290atid=350290 To archive this, we need to change the internal representation of track number as strings, which is currently integer number. I think it may be a small change, but do not good for 3.x branch. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] lame 3.96.1 and the chipmunk effect
From: Joe Auty [EMAIL PROTECTED] Subject: [mp3encoder] lame 3.96.1 and the chipmunk effect Date: Thu, 12 May 2005 01:08:39 -0500 How is Lame 3.93 different than 3.96.1? Am I stuck using this much older version of Lame, or is there a fix with the new version? LAME3.93 uses 22.05kHz as sampling rate when --abr 56. LAME3.96 uses 24.00kHz as sampling rate when --abr 56. check -s 22 option with lame 3.96.1. If the problem is solved, the player you used may have a problem with 24kHz mp3. If not, I have no idea. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: Antwort: [mp3encoder] Lame national chars
Hi, Kim. From: Kim S. Andreasen [EMAIL PROTECTED] Subject: RE: Antwort: [mp3encoder] Lame national chars Date: Mon, 14 Feb 2005 22:57:57 +0100 The solution (well, I would rather call it a woraround...) to the problem consists of two quite easy steps: 1) When writing the batch file from the Windows program I ensure a proper translation to ASCII, code page 850 (or 865). 2) I include an extra first line in the batch file in which I set the code page before Lame starts: MODE CON CP SELECT=850 (code page 865 is for Denmark/Norway, #850 is for (most of) Western Europe, as far as I remember) This has worked very well for several hundred files now! Thanks again for your help. Great digest ! Could you allow us to these instructions to the LAME FAQ ? -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] huffman frequency lines restriction
From: Ondrej KUTIK [EMAIL PROTECTED] Subject: [mp3encoder] huffman frequency lines restriction Date: Mon, 21 Feb 2005 13:54:51 +0100 does the number of frequency lines to be decoded by huffaman have any upper limit? normaly i would expect the upper limit to be 576. but i have seen some code where the upper bound is set according to the last scalefactor band. (i.e. 522 in case of MPEG2 22.05 kHz). could you please explain this? I think it is the DIRTY hack to reduce the complexity of decoding. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Lame national chars
From: Kim S. Andreasen [EMAIL PROTECTED] Subject: [mp3encoder] Lame national chars Date: Mon, 7 Feb 2005 19:05:11 +0100 I can't get Lame (3.92 3.96) to dance with sound files having non-English characters in their names. It simply ignores such files. The same goes for ID3 tags. At best they get converted (my guess is that the MSB gets stripped off). That is probabry the problem of your shell (like DOS-prompt). I have no problem with my national character (kanji and kana and hira-gana), on my linux box. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] processor specific build of lame under mingw gives errors
From: Alexander Leidinger [EMAIL PROTECTED] Subject: Re: [mp3encoder] processor specific build of lame under mingw gives errors Date: Sun, 30 Jan 2005 17:45:39 +0100 To this: NASM_FORMAT = -f win32 -DWIN32 you have to make the change in the lame-3.96.1/libmp3lame/i386/Makefile I'm interested to see the build system type line from the configure run to be able to autodetect this case. Investing other software's configure script, it seems build system type is mingw or mingw32. I've just committed the experimental patch to my experimental branch. See configure.in revision 1.83.2.34. But... I have no environment to test it. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] How to correctly compile lame with mingw
From: Robert Hegemann [EMAIL PROTECTED] Subject: Re: [mp3encoder] How to correctly compile lame with mingw Date: Sat, 29 Jan 2005 13:29:26 +0100 the compiler does not have lame/mpglib in its list for include files. simple fix: edit libmp3lame/mpglib_interface.c line 13 to #include ../mpglib/ interface.h Right. The problem is in the include path configuration. But, it sounds strange to me, because the commandline, gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I. -I../mpglib/ -I.. -Wall -pipe -march=athlon-xp -Wall -fstrength-reduce -finline-functions -freduce-all-givs -m3dnow -msse -mfpmath=sse -mmmx -O3 -pipe -fforce-addr -fomit-frame-pointer -funroll-loops -frerun-cse-after-loop -frerun-loop-opt -falign-functions=4 -maccumulate-outgoing-args -fprefetch-loop-arrays -mtune=athlon-xp -MT mpglib_interface.lo -MD -MP -MF .deps/mpglib_interface.Tpo -c mpglib_interface.c -DDLL_EXPORT -DPIC -o .libs/mpglib_interface.o contains -I../mpglib/. Ummm, really strange. FYI: I can successfully compile them on cygwin with the option -mno-cygwin, but I have no pure mingw environment. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Re: Some Amd64 timings
From: Gabriel Bouvigne [EMAIL PROTECTED] Subject: Re: [mp3encoder] Re: Some Amd64 timings Date: Sat, 28 Feb 2004 16:16:11 +0100 As gcc should be able to utilize MMX, SSE, SSE2 and 3dnow with inline assembly now, it would be nice if someone would try to use it instead of using a 3rd party assembler. In short, they should be easier to use well than raw assembly, whether inlined or external. Isn't intrinsics specific to the compiler, with gcc intrinsics not usable with VC or ICL, and VC intrinsics not usable with gcc? Yes. they are same between ICC/VC6+Processor Pack/GCC, at least for SSE/MMX intrinsic, because Intel standarized and offered the header The problem is about 3DNow!. It is only available for VC (from MS) (and maybe on icc on windows). No gcc support and no none-windows support for it (unless you break the license ...) -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] safe to use NASM-SSE in LAME ?
From: rocko [EMAIL PROTECTED] Subject: [mp3encoder] safe to use NASM-SSE in LAME ? Date: Thu, 19 Feb 2004 11:07:56 +0100 Can anybody tell me if i am safe with using the NASM-SSE now ? No, it's not safe. I think we should remove it at least from the release package. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] lame and files larger than 2Gb
Hi, Michelangelo! Over 2GB support was requested for a long time. http://sourceforge.net/tracker/index.php?func=detailaid=849889group_id=290atid=100290 But it is quite hard to support it flawlessly (at least for me...) From: Alexander Leidinger [EMAIL PROTECTED] Subject: Re: [mp3encoder] lame and files larger than 2Gb Date: Thu, 29 Jan 2004 16:10:31 +0100 On Thu, 29 Jan 2004 13:43:27 +0100 Michelangelo Nottoli [EMAIL PROTECTED] wrote: (question 1) can anyone suggest the correct #ifdefs for fopen/fopen64 calls? something like... #if defined(__unix__) || defined(__sun__) ...call fopen64 #else ..call fopen #endif sounds correct ? The should be a configure test for fopen64. If the function is available it can get used. IMHO, it is not sufficient to replace fopen. You need to replace all the fseek(), ftell(), ... and variable type to store the result of ftell64() and so on. Of course, you should use configure for all of them. (question 3) do you think there is need to open the output stream also with fopen64 ? I think it would be better. Output may be bigger than input (when with --decode), so it is important. But, by default, the output of decoding is RIFF-wave which does not support over 2GB So we have to check the length of decoded data. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Integrating LAME and VBRFix?
Hi. A current limitation of LAME is that it does not write VBR headers correctly. Someone says does not, someone says it does. :) The functionality of VBRFix seems straightforward enough. It would be great to have LAME also do this by default, so that MP3 files are properly encoded out of the box. Has anybody already tried to integrate VBRFix's functionality into LAME? probabry no. Are there any good reasons not to do this? Because no one want to do, Or no one has a spare time to do so, Or no one really think it problem, Or everyone think it was fixed. As for me, I am not much interested in it and am not willing to fix it. It would be a great project to work on, if there is demand for it. I will try to find the time to help, if needed. Do you write the code ? If yes, it sounds great. Let's write and contribute it to us. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] lame_get_encoder_delay(gfp) returns 0 if there's no LAME Tag
From: Branimir Amidzic [EMAIL PROTECTED] Subject: [mp3encoder] lame_get_encoder_delay(gfp) returns 0 if there's no LAME Tag Date: Sun, 07 Dec 2003 23:30:28 +0100 If there's no LAME Tag after Xing Info Tag this function returns 0. But if there's no Xing Tag at all this function returns 576. Is this OK? Don't know, but maybe bad. 576 is the shortest delay mp3 can archieve. (except we use the short block at the beginning). So IMHO, returning 0 is wrong. Also, what encoder delay value should I use if there's no Xing/LAME tag when decoding an MP3 file? Does it depend on what encoder was used for encoding that song? Yes, it depends. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Masking in LAME
From: Gabriel Bouvigne [EMAIL PROTECTED] Subject: Re: [mp3encoder] Masking in LAME Date: Thu, 20 Nov 2003 13:38:35 +0100 Lame is using a tonality estimation. Tonality can be estimated by using peak detection method (Gpsycho) or predictability (NSpsytune). I think gspsycho uses predictability and nspsytune uses peak/avg ratio as tonality. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Scalefactor Coding
From: Ville Leino [EMAIL PROTECTED] Subject: [mp3encoder] Scalefactor Coding Date: Wed, 12 Nov 2003 15:08:36 +0200 (EET) ISO 11172-3 states that part2_length = 11*slen1+10*slen2 for long blocks. However, scfsi[scfsi_band] flags are supposed to indicate whether data is to be copied between granules yet the part2_length formula doesn't take this into account. Am I missing something here? Should I just skip enough bits so that part2_length condition is met before proceeding to decode the actual spectral values? part2_length is not part2_length[gr][ch] nor part2_length[ch]. And as you say, you should consider in scfsi[scfsi_band] (or scfsi[scfsi_band][ch]) value when you decode scalefactor value. --- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] r3mix site is gone!
From: Alexander Leidinger [EMAIL PROTECTED] Subject: Re: [mp3encoder] r3mix site is gone! Date: Tue, 23 Sep 2003 12:05:06 +0200 On Mon, 22 Sep 2003 21:54:16 -0400 Mike Caldwell [EMAIL PROTECTED] wrote: Is there any chance any of the info from the old re3mix.net site could be moved to the official LAME project web site? I think it was a handy resource, and it would be great if that information was still publicly available. Thanks, The LAME webpages are available from sourceforge CVS, feel free to send enhancements to [EMAIL PROTECTED] But I don't need anything except hydrogenaudio.org about this region. IMHO, r3mix is already obsolete and brings only wrong information... -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] LAME setting for speech encoding
From: Rich Koziol [EMAIL PROTECTED] Subject: Re: [mp3encoder] LAME setting for speech encoding Date: Tue, 12 Aug 2003 18:24:43 -0400 Thanks Takehiro, On 9 Aug 2003 at 20:55, Takehiro Tominaga wrote: From: Rich Koziol [EMAIL PROTECTED] Subject: [mp3encoder] LAME setting for speech encoding Date: Wed, 06 Aug 2003 14:06:55 -0400 Can someone suggest command line settings with appropriate low/high filters. I would like to stay in the 32-64kB/s range. use --preset abr 40 or so. LAME's VBR is usually inferior to ABR/CBR at these bitrate. -- Takehiro TOMINAGA // may the source be with you! Will give that a try. Would ABR be preferred to CBR? I guess, at that bit rate quality is not a great concern. I think there's no big quality difference between CBR/ABR, at that bitrate. But ABR uses the minimum bitrate if it detects analog silence. It makes better compression ratio for the voice materials. I recommend ABR if you have the special reason like your player supports only CBR file. Any cut off filters? ...or will filters come with the ABR? --preset sets the many parameters including filter freq. automatically. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] LAME setting for speech encoding
From: Rich Koziol [EMAIL PROTECTED] Subject: [mp3encoder] LAME setting for speech encoding Date: Wed, 06 Aug 2003 14:06:55 -0400 Tried to search the archives, but on the present server they do not seem to be searchable. Google does not produce any useful results either. Sorry if this was covered before. I'd like to encode some speech, which had perviously recorded on tapes. While there are many presets available for high end encoding, I do not see any for the speech range. Can someone suggest command line settings with appropriate low/high filters. I would like to stay in the 32-64kB/s range. use --preset abr 40 or so. LAME's VBR is usually inferior to ABR/CBR at these bitrate. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] [PATCH] to LAME to convert RIFF LIST tags to ID3tags
From: Charlie Lenahan [EMAIL PROTECTED] Subject: [mp3encoder] [PATCH] to LAME to convert RIFF LIST tags to ID3 tags Date: Sun, 29 Jun 2003 15:53:11 -0400 For those that have ripped all their CD's to wav w/ LIST tags, like those used by the Audiotron. This patch will set the ID3 tags when converting a wav = mp3 Thank you for the good patch. I merged this patch into LAME4. From: Gabriel Bouvigne [EMAIL PROTECTED] Subject: Re: [mp3encoder] [PATCH] to LAME to convert RIFF LIST tags to ID3 tags Date: Mon, 30 Jun 2003 10:07:23 +0200 Thank you for your submission. This should be included soon into Lame. I think we need some documentation before merge into main branch. Charlie, could you confirm below items are true ? - Using this patch, ID3 Tags are set by reading LIST chunk of RIFF file. - Tags in LIST chunk will be converted to ID3 tags as follows. * INFO tag is ignored * INAM tag is converted to Track number of ID3 tag. * IART tag is converted to Artist Name of ID3 tag. * IGNR tag is converted to Genre Name of ID3 tag. * IPRD tag is converted to Title of ID3 tag. * ITRK tag, which is an extension used by Turtle Beach's Audiotron, is converted to Track Number of ID3 tag. - It works only when libsndfile is not used. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Why adj43[] ?
From: nimaje mohan [EMAIL PROTECTED] Subject: [mp3encoder] Why adj43[] ? Date: Thu, 26 Jun 2003 01:44:24 -0700 (PDT) Hi, Can anybody tell what is the purpose of adj43[] array in quantize_xrpow() in LAME MP3 Encoder? I mean why is this adjustment required? Also I didn't understand, why adj43[] array is initialised the way it is done. See the comments before quantize_xrpow() function. * nonlinear quantization of xr * More accurate formula than the ISO formula. Takes into account * the fact that we are quantizing xr - ix, but we want ix^4/3 to be * as close as possible to x^4/3. (taking the nearest int would mean * ix is as close as possible to xr, which is different.) That's all. adj43 is initialized to fit the requirement. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] psychoacoustic model based on MDCT
From: Gabriel Bouvigne [EMAIL PROTECTED] Subject: Re: [mp3encoder] psychoacoustic model based on MDCT Date: Wed, 18 Jun 2003 11:01:57 +0200 i would like to know if there is any possibility to improve encoding speed by combining the 2 transfomations (MDCT + FFT) by exchanging the psychoacoustic model transformation (FFT) with an MDCT and then reducing the two MDCTs to one. is there already an implementation? and where can i find more information concerning this topic? This should be possible as some AAC encoders are working this way (Psytel and Nero). Yes, that's so called CMDCT. However, the fft transform is not that slow compared to the overall speed (at least in Lame) You're right. FFT is not slow at least in LAME. This is why the FFT with 3DNow!/SSE does not make significant result. By profiling the LAME, FFTs (for long and short) takes only about 4.5%. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] q0
From: Paul Roberts [EMAIL PROTECTED] Subject: [mp3encoder] q0 Date: Wed, 11 Jun 2003 00:25:26 +0100 I read that LAMEs -q0 is broken from 3.90 onwards, which seems to be born out by listening tests. 3.88 q0 sounded very good to me. Is there a way of reproducing what that was doing in later LAMEs? -q0 on 3.88 is almost same with -q2 on LAME3.90 to LAME3.93.1, and -q3 on LAME3.94 alphas. And they are the default setting of each of them. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Profiling LAME on Altivec Machine
M == Martin Hairer [EMAIL PROTECTED] writes: M There was some discussion on this list about interfacing lame M with Apple's G4 optimized FFT routines. Surprisingly, it seems M that lame spends basically no time computing FFT's on my G4 M machine, but mostly square roots... At the lowest quality M settings, the percentages spent in the various routines M according to Shikari are as follows: Probabry so. The biggest problem on NOT INTEL machine is that IEEE_754 related hack is not enabled by default. These hacish code significantly speed up the code in quantize_xrpow(), log(), log10(), and so on. If you have a some new machine and want to fasten the LAME on it, try to enable these hacks. Define TAKEHIRO_IEEE754_HACK symbol and you can enable them. If you get faster and proper result, pls report it to the list with the your system descripton. We will update the configure script to enable these hacks by default. 10.0% count_bits 3.7% ix_max They are already SIMDed on ix86 machine with MMX. I think at least ix_max() is easy to SIMDed. 3.8% sqrt You may speed up the sqrt() by changing sqrt(x*sqrt(x)) to some polymorph. Probabry this mail will help you. http://sourceforge.net/mailarchive/forum.php?thread_id=1209312forum_id=5500 -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
best huffman divide for MPEG2/2.5(Re: [MP3 ENCODER] On thehardware decoder issue...)
M I notice that best_huffman_divide() is specifically disabled
M for short blocks in MPEG 2/2.5. Does any one remember why this
M was done?
Ok, I found the reason. It's easy bug, after all...
Enabling the best_huffman_divide() for MPEG2/2.5 short blocks,
LAME simply stops with assertion faulure in bitstream.c
And I found the bug is in the counting bits.
In best_huffman_divide().
if (cod_info2.block_type == NORM_TYPE)
recalc_divide_sub(gfc, cod_info2, gi, ix, r01_bits,r01_div,r0_tbl,r1_tbl);
else {
:
a1 = gfc-scalefac_band.l[7 + 1];=== HERE
if (a1 i) {
a1 = i;
}
For all the not NORM_TYPE block of MPEG1, the huffman division point is
same. But MPEG2/2.5, they differ from SHORT to STOP or START.
I fixed this and enabled best_huffman_divide() for MPEG2/2.5.
And it works fine now (with my little tests).
The fix is already done in my experimental branch.
Any comments ? If it is right answer to fix the problem, I will
backport to the main branch.
--
Takehiro TOMINAGA // may the source be with you!
___
mp3encoder mailing list
[EMAIL PROTECTED]
http://minnie.tuhs.org/mailman/listinfo/mp3encoder
FAQ (Re: [MP3 ENCODER] ALL VESIONS BUG !!!)
G == Gabriel Bouvigne [EMAIL PROTECTED] writes: G (we really need a good FAQ) Seems there's tech-FAQ compiled by Mark. http://lame.sourceforge.net/tech-FAQ.txt is it. But I agree it is too much technical Does anyone willing to compile the FAQ ? -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Problems decoding an Mp3 file...
M == Martin Hairer [EMAIL PROTECTED] writes: M When I call lame --decode Chris.mp3 Chris.wav M where Chris.mp3 is the file available at M http://mpej.unige.ch/~hairer/Downloads/Chris.mp3, I get the M following output: : M Segmentation fault It because Chris.mp3 seems have an ID3 tag and lame does not support it. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Does lame support layer-1 and layer-2
C == Chetan Krishnamurthy [EMAIL PROTECTED] writes: C Does lame support layer-1 and layer-2. No. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Re: Unconvertable file! (plain text post)
D == Dan Nelson [EMAIL PROTECTED] writes: I need to convert that file to smallest possible MP3 for playback on the web via Flash v4.0 (non-streaming) and Flash v6.0 (streaming). The content will *always* be voice so I'd like to use something equivilent to lame's phone or phon+ encoding. No matter what LAME options I try, all I get is screeching! D Lame doesn't recognize mu-law encoding. Try converting it to D 16-bit signed with sox, then pass the wav file through lame. D sox -bU -r 8000 -t raw 44.pcm -uw 44.wav Or build LAME with libsndfile enabled. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] what is with the new version
A == Alexander Leidinger [EMAIL PROTECTED] writes: There is not yet any support of any SSE or SSE2 optimizations into Lame yet. Only MMX and 3DNow are there. This is likely to be something that is compiled by mixing some files from Gogo and fron Lame. A Or they refer to SSE2 instructions generated by icc 7. I hadn't A time to test it with icc 7, but MMX instructions generated by A icc 5 slowed down lame a little bit (this is independend of the A nasm MMX code). Just FYI: It seems icc7 is not good for LAME compiling, at least for me. With icc7, LAME slows down about 10% comparing icc6. And, With icc6 and -fno-alias option for the compiler, I got one more (about 1 or 2%) speed gain. But with icc7, I cannot use -fno-alias, because it cause an internal compiler error for many files. My test is done on my Duron 1GHz, Linux2.4.20, 384MB memory. I don't have and don't know about the P4 box, but at least for me, icc7 was not good as I expected... -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] suggestions for -b 96 defaults
If LAME made --alt-preset 96 or something thereabouts the default, then this would solve the problem in SHOUTcast and would also obviate the need for --alt-preset 96. In other words, why make crappy the default? Changing default setting needs concensus. And at least for me, I disagree to replace with --preset XXX of the current default setting. 1. It slow. You won't say CRAPPY only from the encoded sound quality. 2. Some people says, and I confirmed preset decrease the sound quality in some case. But these problem is almost (but not perfectly) solved in the experimental branch. 1. is solved by the huge structure change and optimization, 2 is solved by block switching code fixes. Maybe LAME 4.00, --preset with more tuning will be the default IMHO. ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] --alt-preset ultimate description
A == Alexander Leidinger [EMAIL PROTECTED] writes: A On Sun, 17 Nov 2002 15:01:49 + Dominique A [EMAIL PROTECTED] wrote: Please note, I dont mean --alt-preset help, I want to know how the presets translate into all this -x -y -z -e -t -c. stuff manpage (and r3mix.net) is full of ;) A You can't fully emulate --preset with distinct switches. It A does more behind the scene. Currently, you can emulate ABR/CBR preset, but VBR preset (standard, extreme, and so on), you cannot. And except something which we cannot emulate, you can see the rest of setting by using --verbose option, like lame --alt-preset standard --verbose in.wav out.mp3 -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] FFT - fht.c - optimisation for Altivec on Apple
Hi, ruffnex. I am looking forward to AltiVec optimized LAME :) r == ruffnex [EMAIL PROTECTED] writes: r After gprof'ing Lame 3.92, and looking at the source, I think r fht.c might be an ideal candidate for vectorising with OSX's r Altivec optimised DSP library. Yes, the code is easy to optimize with the SIMD instructions but currently, only 3DNow!-ed code is available which I ported from GOGO. r (1) Function arguments r static void fht(FLOAT *fz, int n) r *fz = ptr to time-domain data (in what order ?) the order is 'bit-reversed series order'. See the fft_short() and fft_long() functions in fft.c for the details. r n = the size of the input data to transform e.g. n-point dft r (what is the valid range for n ?) only 256 or 1024. r (2) the function is in-place (that is, the input data is r over-written by the output data) yes, you are right. the calculation is done by in-place algorithm. -- Takehiro TOMINAGA // may the source be with you! ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] File format of mp3
Why are there mp3 files in which the value of part2_3_length is zero? e.g. http://php.s3.to/bbs/up/img/216.png Isn't the part2_3_length length of main data per 1granule, 1channel? Because the frame contains totally no sound (the frame is digital silence). ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
