[mp3encoder] Peter Gubanov
I regret to inform you that Peter Gubanov, Elecard co-founder, was killed in an avalanche on 2nd March, 2007. (I am only becoming aware of this now) Peter provided us with the DirectShow filter implementation for Lame. -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] lame removing samples with --resample?
Thomas Orgis a écrit : Hi! While hacking around with mpg123 to get rid of encoder/decoder delay and padding I stumbled over lame apparently removing samples when using --resample. I assume that this indeed should work (or is it experimental?). I documented my (days of) work at http://mpg123.orgis.org/lame-resampling.shtml I'd be thankful if someone could comment on that. Well, this could possibly be a bug of the resampling. -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Questions about LAME frames found in a users MP3
Edouard Poor a écrit : when there is not enough audio data to fill the frame. This is stored into ancillary data, and is ignored by decoders. But the frame's audio data *starts* with LAME3.93UUU, and there =20= are another 77 frames of the same thing following. That seems =20 completely unlike just padding the last frame out to it's full length =20= if the audio data is less than a frame size. It's likely that there is NO audio data on those frames. If you encode silent parts, Lame would not find anything to encode and would fill the space with padding. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org https://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Question about Subband filtering
YUE LI a écrit : As I know, both psychoacoustic model and quantization use scalefactor bands, not equally divided subbands. So why Polyphase subband filtering is performed in the beginning of encoding? It's just to keep a decoding step identical between layer II and layer III. From an engineernig point, it simply makes no sense. When this was decided, it made sense considering a financial/strategic point of view. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] bug in id3v2 ??
Takehiro Tominaga a écrit : I just fixed it on trunk (The experimental branch is not affected because the tagging code is changed at all to support UTF8). Should I back port to 3.97 branches ? Yes, please -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Cannot Compile on MS VC++ 2005 Beta 2
Robert Hegemann a écrit : Hi Travis! What are you compiling exactly? lame.exe? lame.acm? How do you compile lame? via Makefile or Projectfile? 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. -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Cannot Compile on MS VC++ 2005 Beta 2
Takehiro Tominaga a écrit : 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 You are right. I had a look at configMS.h, but not at machine.h -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Warning: corrupt or unsupported WAVE format
--- rec02.wav: RIFF (little-endian) data, WAVE audio, IMA ADPCM, mono 8000 Hz --- 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? Your wave file is not plain raw pcm, but coded using adpcm. The standard Lame build does not support this as input. Use libsndfile enabled lame. As Takehiro said, Lame can be build with libsndfile handling the input. In this case it would work. Another solution would be to open you file in an audio editor and save it as uncompressed pcm wav file. (it might even work with the basic sound recorder shipped with windows) Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Multithread patch inclusion ?
David Balazic a écrit : Is/will the multithread patch at http://softlab.technion.ac.il/project/LAME/html/lame.html be integrated into lame ? Gives 20-100% speedup on 2-way systems. (hyperthread,dual-core,SMP etc. ) It produces bit identical output to classic LAME (according to author, I compared his version with a newer lame version and they differ) In its current state, this patch will not be included into Lame. In order to work properly, this version needs to have the bit reservoir disabled (it is thus only bit identical to Lame if you add --nores to Lame options). Disabling bit reservoir will cause serious quality reduction. It is an interesting work, but practically encoding the mp3 stream in 2 half parts by 2 instances of Lame in parallel and then joining them would provide the same speed benefits as this version, but with a way higher quality. Those who want to use 2-way (or more) systems can also encode several tracks in parallel with several instances of Lame. You will have some nice speed boost, with zero quality reduction. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Re: how to create -true- raw mp3 with lame
...the string lame 3.97 is human readable only within the last bytes of the file. There is a kindof trailer consisting of AAA... with the mentioned string in it. The Fraunhofer files don't show this... This string is stored into ancillary data, and the frame is perfectly compliant (btw the Lame header is also a compliant frame). A decoder having problems with ancillary data is likely to have problems on many mp3 files. No, when I encode the files with the Fraunhofer coder (same format) the files are accepted. Suggestion: try without -m s. Some decoders are not able to deal with some encoding modes (still compliant) we are using in separated stereo. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] encoding several tracks as one mp3 file?
Dave Yost a écrit : Can this be done with lame? There are CDs with continuous music broken into tracks, and when you encode them as separate mp3 files and try to play them back, you get annoying gaps, apparently because of some quantization issues with mp3. Lame stores those values into the header of the file. If you use a player able to read those info, the decoding will be gapless. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] speed (was: Converting .m4a (Apple Lossless) files to LAME .mp3)
J-FOX a écrit : Hi, I'm using LAME v.3.96.1 to convert .m4a files in iTunes using the following settings: --preset cbr 320 -q 0 -ms My results are unacceptably sluggish performance even with a dual processor Mac running at 2.0GHz. Is there any way to tweak LAME to perform better on this platform without sacrificing quality? It is slow because you specified -q0. According to the help -q0 will theorically use the highest quality possible, whatever the speed. It is thus perfectly normal that the encoding is slow. Just use --preset cbr 320 and your encoding will be way faster. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] mp3 downsampling
LAME4 experimentaly supports the preserve TAGS when transcoding/encoding but it is experimental feature. In the meantime, you could use a program that is copying tags between two files. I know that such a program exists, but I do not remember its name. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] -0.44 dB RMS
Why does Lame's CBR and ABR modes reduce the amplutude of the sound data by 0.44 dB (RMS) while VBR tries to preserve it and succeeds. Can I turn it off? Thanks. use --scale 1.0 option with ABR/CBR encoding. Regarding why, this is to prevent occasionnal clipping on the decoder side. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list mp3encoder@minnie.tuhs.org http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Adjusting equaliser
Ytsen de Boer a écrit : For a while I've been googling around to find out how I could adjust the equaliser while laming from .wav to .mp3. I want more bass in certain tracks. I thought I should use the next options (from the `lame --help' command): --ns-bass x adjust masking for sfbs 0 - 6 (long) 0 - 5 (short) --ns-alto x adjust masking for sfbs 7 - 13 (long) 6 - 10 (short) --ns-treble x adjust masking for sfbs 14 - 21 (long) 11 - 12 (short) --ns-sfb21 xchange ns-treble by x dB for sfb21 --shortthreshold x,y short block switching threshold, x for L/R/M channel, y for S channel I am sorry, but Lame does not support equalization settings. Those settings are only related to psychoacoustic maskings. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] ATH Type and Noise Shape
[EMAIL PROTECTED] wrote: My question is: Is the ATH Type 3 curve and the noise shape Type 2 better when using with -q0 and -V0 then the current one? You would better keep the default settings Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Re: LAME...
Giancarlo Vercellesi wrote: A simple question about MP3 license. If someone use LAME (a free MP3 encoder) to stream MP3 over Internet (or to storage on disk) for commercial market (also suppose to take more than $100,000), he/she must pay a royalty to Fraunhofer-Thomson? Yes. The encoder used is not relevant in this case, as the fees are regarding mp3 technology, and not about a specific mp3 implementation. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Re: LAME...
Monty wrote: If you use the encoder, you must have purchased a patent license period. Of course, MPEG isn;t going to concern itself with individuals. If you do it in the name of NPR, you really really need to have a real license :-) Sorry Monty, but if someone is using an encoder for the sole purpose of creating some streams, he/she doesn't have to acquire a license. The DISTRIBUTOR of the encoder should obtain the license, but not the end-user. Otherwise every MusicMatch user should acquire a license... Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] custom command line (was: Looking for programmer)
Thats how i got this: lame -q0 -X6 -ms -d --lowpass 20.05 --cwlimit 11.025 -Z --scale 0.98 --scale-r 1.1 --scale-l 1.1 --ns-sfb21 2 --nspsytune -v -V0 --vbr-rh --abr 172 I hope your are not serious. In case you are, here are a few points: *As already explained, --scale-l, --scale-r and --scale are redundant and can be combined into a single --scale *--vbr-rh is the default vbr mode, so this switch does nothing in your command line *--cwlimit has no effect when using --nspsytune *--nspsytune is the default mode, so this switch does nothing in your command line *-v before -V0 does nothing, as -v is already activated by -V0 Considering that your custom command line is including several useless/redundant switches, I think that you are experiencing a simple placebo effect. You should try using double blind tests to test your command line against the simple (but efficient) --abr 172 regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
[mp3encoder] Re: [Lame-dev] LAME Psychoacoustic model.
Vijayasaradhi D. wrote: I know that LAME used its own Psychoacoustic model. I am trying to understand different psychoacoustic models..like in 11172-3 Psycho1 , Psycho 2..etc. Where do I can get document describing LAME Psychoacoustic model. The psychoacoustic models are not very documented, but you can check the following: *lame website (gpsycho related pages) *source code comments *http://gabriel.mp3-tech.org/lame/diagrams/ regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Latest build still has errors (decoding)
Kristian Hermansen wrote: You were correct. The decode was the problem and here is the output: --snip-- I uploaded the problematic portion of the mp3 file on http://gabriel.mp3-tech.org/lame On decoding this file Lame is crashing (access violation) Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] 24-bit wav vbr issues
Lars Rosenberg wrote: I don't think Lame can handle 24 bit wave files. You probablyhave to convert the 24 file wave file to a 16 wave file first. You might have to start use Fraunhofers MP3 Encoder in stead. If I where you I should check out if the Fraunhofer mp3 encoder can convert to 24 bit mpeg stream. I'll try to check that in my source that I got from Fraunhofer. Lame supports 24bits wav files fine, and is able to encode in vbr. (to be sure that there was no bug I just tryed, it works perfectly) regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Question
Christopher Gorrie wrote: I have dynamically linked the LAME Dll to my program and was wondering whether there is any way to write tags (ID3V1 or ID3V2) to the MP3's. Is it just not part of the library yet? Well, it is part of libmp3lame, but not exposed by the dll. You will probably have to wait for lame v4 to have it in the dll. In the meantime, there is the possibility to use the static libmp3lame. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Re: Some Amd64 timings
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? Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] [ Ask for LAME Mp3 encoder authorization]
karen_wang wrote: We have read the article about ??Can I use LAME in my commercial program??? We would like to ask you for helping us to get/obtain the legal authorization or can you tell us how to obtain the legal authorization? Is there anythig in particular that we have to look out for if we use your MP3 encoder? We (Lame developers) are providing you a technology implementation of mp3 encoder. According to the license we are using (LGPL) we grant you the right to use our code provided that a) you mention in your program that you are using our encoder b) if you modify our source code, you have to make those modifications freely available But the mp3 technology is covered by patents that we do not own. According to your country, you might be required to obtain a license permission on the technology (see mp3licensing.com). By using Lame, you are saving cost on technology implementation, but we can not do anything regarding potential patent fees. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
[mp3encoder] Re: [Lame-dev] Re: Amd64
Fred Nevez wrote: Men i do not understand , why do not do like everyone , buy yourself a computer ?? We already have computers. i'm without job , and only try to help , i really do not see any point why i would buy a computer only for a codec We do not see any point either about why should we buy new computers just to please someone. I know tons of people who would dev and compil me EVERYTHING they find if i gave them a 64 bits cpu+mobo You are asking for development, not just compilation. It is not that easy (otherwise you would have done it yourself, don't you?) i was thinking you all doing that for fun and i notice it's more to have stuff and to complain a bit too have them.. We are working on Lame for fun, and are not complaining. You are the only one to complain here. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] mpglib
Frances Buck wrote: I try to port my app frin windows to os x. So I think I need to build libmp3lame.a and mpglib.a. The fist one will be created if I start (./configure, make, ... ) but I I miss mpglib.a. ./configure --help will give you the list of options. There is one to enable mpglib Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
[mp3encoder] Re: [Lame-dev] Re: Amd64
I let Gabriel or someone else comment on that as I definitively can't help on the ACM part. Maybe he can provide you with some kind of a debugging version of the ACM to find the cause of the problem. i'll continue to use the old radium codec :/ i was thinking the lame dev team would be proud to be one of the 1st to do 64 bits codecs but seem not Well, I think that it would be nearly impossible to correct the ACM for 64bits systems without access to such a computer. There are mainly 2 ways to have the ACM version working: correct it yourself, or ask someone to correct it. I can not personally correct it, as I do not have any x86-64 computer. If you want to speed up the process, you could donate a 64bits computer (or its financial equivalent) to one of the Lame developers. As already explained, we are not getting paid for working on Lame, and so can not afford to buy a new computer just to port Lame on it. In the meantime, I think that the command-line version should work just fine on your new system. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Re Problem with Long Time Encoding - Lame 3.95
Sir Gorgoroth wrote: We have very big problem with new lame version 3.95. When I encode wav. files to mp3 files it's takes very much time. One song at about 5 min. encoding 30-40 minutes at the In old lame version 3.93 this operation takes only 1-3 It seems that you forget to mention details of your problem, like wich settings you are using. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] ATH Masking
DigitAl56K wrote: I'm currently encoding a bunch of my CD's using the following switches to LAME 3.95.1: -p -k -q 0 -V 4 -m s With 3.95.1 I would suggest you to just use -V3. The resulting bitrate should be similar to your current command-line and the quality will probably be better. It sounds as if LAME is cutting the hiss in and out in the quiet sections of the track leading to very noticeable artifacting. Presumably this has to do with the ATH level. Maybe some investigation of this issue might lead to a more accurate ATH model that was more adaptive and thus produced better quality. Perhaps your track has an unusually low volume? Have a look at the ReplayGain value displayed at the end of encoding. It gives the adjustement needed for the track to reach a perceived loudness of 92dB. If it is displaying a big adjustment value, like +15dB or something similar, then maybe you should use add --scale to your encoding. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] LAME: Problem encoding some files...
Kristian Hermansen wrote: I had some trouble encoding a few files. LAME crashed on me a few times and First, we need a few information: *version of Lame *compiler used (eventually) *parameters used *does Lame crash on every files or just some specific files *does Lame always crash on some files, or does it sometimes manage to encode them Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Effect of perceptual entropy on quality
Manjunath D N wrote: Bit rate : 128 kbps When I increase the default Perceptual entropy from 700 all the way upto 3000 I see no improvement in quality. I thought that the Bit allocation module would allocate more bits to each frame if I increase the PE( If your are using a 128kbps fixed bitrate, how would increasing the default PE increase the number of allocated bits. The allocated bits are constrained by the bitrate when using cbr. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Lame MP3 Encoder - 3.94version
Narayanan wrote: I would be highly obliged if any of you can provide me a good documentation/information on the latest LAME MP3 encoder code flow.I have downloaded the version 3.94 and started analyzing the same. Also if anyone can guide me through the initial phase, it would be good. I uploaded some diagrams to http://gabriel.mp3-tech.org/lame I made them about 1 year ago, so them might not be up-to date. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Noise treatment in LAME
[EMAIL PROTECTED] wrote: I am reading the source code of LAME. I wonder how LAME deals with noise such as white noise and band-pass noise. Does the tonality estimation in LAME work on tone only? The goal of the tonality estimation is to give a tonality value. So a white noise or a band pass noise will have a very low tonality value (idealy 0). Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] [VickyWeng@Grandex.com.tw: About Licence Issue]
Vicky Weng wrote: We have a question about licence issue need your esteem company's help. We will use your LAME 3.93 into our product, and then attch this utility to our customers. So we wonder if there will be any licence issue happened. Please give us a clear instruction. As Lame is lgpl, what you have to do is to clearly state that you are using Lame in your product. If you modify Lame for your product, you need to make your modification source code available for the public. Independently of our license, according to your country you might need a patent license in order to use any mp3 technology. We are saving you the cost of technology implementation, but are not able to provide you a license agreement on the general mp3 technology, are we do not own the patents. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Effect of blocktype mismatch on song quality
Manjunath D N wrote: I am trying to develop an MP3 encoder on a 24 bit fixed point DSP.Due to fixed point degradations, there is a mismatch in the blocktypes that my assembly code psychoacoustic model gives wrt the lame floating point code.For example if for a granule the floating code gives blocktype as 1(START type), my assembly code may declare blocktype as 3(STOP type) I am wondering how can fixed point mismatch 1 with 3. This is more than a precision error. My question to the lame developers is what exactly is the effect of this mismatch on the final mp3 bitstream? This part will not be decodable because according to the standard a stop block can not follow a stop/long block. In the same way, next block will not be decodable neither because a short block can not follow a stop block. Some not so robusts decoders might even totally stop decoding from this point. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
Nils Faerber wrote: Umm... I might be wrong (and if, please excuse) but isn't LGPL exactly for the purpose of being able to link against LGPL'ed works and not violating the LGPL license, be it statically or dynamically? Exactly, but you also have to explicitely mention which lgpl libraries your are using. Nonetheless I think that Lame itself is in violation of the GPL and LGPL since GPL and LGPL explicetly forbid patented technologies under the terms of the LGPL or GPL. And since there is no doubt in the fact that the MP3 technology is patented I even think that applying the GPL or LGPL to Lame is not possible at all - at least in a unaltered version. We had an argumentation regarding this point with Stallman and the only conclusion that was drawn was that he did not care about it. Perhaps we should add an addendum to our license, but until now it seems to fit quite well. The same patent point would also apply to Mpglib, Mad, the Linux kernel,... Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] possible lame LGPL violation
Gabriel Bouvigne wrote: I am writing them a mail asking for clarification about this. Issue solved, next version will include a mention regarding Lame in the about box. -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] May I distribute or redistribute the lame_enc.dll in my setup file?
wrote: May I distribute or redistribute the lame_enc.dll in my setup file? I have read the notification in oddsock's project page. http://www.oddsock.org/tools/dsp_oddcast/#Beta%2030%20Updates Because of LGPL, or patent system of each country? This is because of patents covering the mp3 coding scheme. But the winamp redistribute the lamedll.dll in it's shout source dsp plugin setup package. Nullsoft has a licence agreement covering the mp3 patents: http://mp3licensing.com/licensees/index.asp Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Encode or decode single frame
Branimir Amidzic wrote: Is it possible to decode one single frame of MP3 data (all of main data from previous frame(s) concatenated) to 1152 samples of PCM, and then encode it to just one MP3 frame with LAME? Well, it is quite problematic because mp3 is using mdct, and this is an overlapping transform. I'm developing an application that would reencode only those frames that don't have coupled blocks in L R channel (problem with HW players), but I have noticed that LAME has some ENC/DEC delays, and that worries me. It will not be a single frame. In current Lame, this would be at least 3 granules. Short blocks need transition blocks before and after, so you have (minimal case) the following succession of sizes: long - start - short - stop - long. You need to change the whole start-short-stop sequence. My suggestion would be the following: *Decode the whole bitstream to pcm *correct the offsets if needed in the pcm stream *encode it again in full stereo *do your cooking/mixing between the original mp3 and the new frames that you can grab from the new mp3. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] mp3 dll to encode in real-time
Thierry Klein wrote: [tk] A C dll is not good for a Windows developer since (to my knowledge) it won't link to a Visual Basic development, for instance. A C++ dll is needed on Windows. I am sorry, but a Visual Basic program can easily link with a C dll. In fact it is easier to link with a C dll than with a C++ dll because C is not ABI-dependant like C++, and so you have no problem when using different compilers. For VB programmers, a quick Google search returned this: http://www.zetnet.co.uk/rad/dll.html Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] windows dll to encode in real time from line in or microphone
John Dann wrote: In fact it's so surprising that there doesn't seem to be a COM-enabled LAME, given that this would enable many more less-expert developers to use the encoder easily, that I start to wonder what the reason might be? Is it concern about the MP3 licensing issue, which perhaps might assume greater proportions if a COM-enabled LAME were released with its potential for much greater usage than the current version. Are there some technical issues that I'm ignorant of? Or are the primary LAME developers perhaps a little reluctant to make things too easy for developers in the Windows world, especially the less expert ones? The main issue of Lame developpers is lack of time. You are welcome to write and submit a COM interface if you find it usefull. It is not in Lame yet because: *COM is win32 specific, and the developper needs to be using win32 to write it, which is not the case of all Lame developpers. *we (at least I) are not so sure that using COM is easier than to link with a C dll for a beginner. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Masking in LAME
[EMAIL PROTECTED] wrote: However, as I am new to the masking stuff, I don't understand how the the masking thresholds are computed as they are presented in equations. Could anyone explain how the thresholds are computed? Are there any references available for masking of LAME? Lame is using a tonality estimation. Tonality can be estimated by using peak detection method (Gpsycho) or predictability (NSpsytune). The tonality estimation controls the ammount of masking. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] LAME encoded mp3 plays chirpy on LG DVD-6054 player
Thomas Gallenkamp a écrit : I am experiencing problems playing back LAME encoded MP3s on my new LG DVD-6054 DVD/MP3 player. The same MP3s played perfectly on all other MP3 players (mp3blaster, mpg123, mplayer, Scott 838 DVD player, JVC KD-S891R car stereo) I tested so far. There are distortions on loud treble sounds (especially guitar chords). Sounds like some integer overflow. I used LAME 3.91 and 3.93.1 with 128, 160 and 320 kbit/s, with and without the --strictly-enforce-ISO options. Problem remains the same. On the other hand bladeenc-0.94.2 encoded MP3s will play OK on the LG DVD-6054. (I am pretty sure that the unit is OK hardwarewise. I suspect some subtle firmware problem). Any ideas or same experiences ? Encode in joint stereo instead of plain stereo. This is likely to remove the problem, as it seems that several hardware decoders are not perfectly able to handle a specific (but fully mp3 compliant) plain stereo configuration used by Lame. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Lame Dev
LiFe a écrit : Hi Guys, Out of interest how come lame development has stopped since 2002? Development is not stopped, but slow. That is because of the lack of human ressources, and the lack of time of available ressources. Some of the work is also done behind the scene. As an example, Takehiro is doing a lot of work on the experimental branch. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Scratch noise at beginning of the MP3 file
PGFrank - Tecnocanal a écrit : I'm very sorry, but I don't understand what you mean. I have a program made by somebody else (I don't have the source code). I use that program to convert MYSOUND.WAV to MYSOUND.MP3 and the conversion is perfect. I code my own program USING EXACTLY THE SAME LAME DLL and the MP3 file has the scratch at the beginning. I don't know what am I doing wrong. Perhaps you considered the wav header to be sound data. Perhaps you forget to write vbr header/info tag Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Confusion at which LAME version one should use
[EMAIL PROTECTED] a écrit : -q0 definitely sounds worse to me than -q2 in recent versions. If it was better it would likely already be used by --alt-preset standard. I believe Takehiro can confirm it is 'broken' in 3.90 onwards. Interesting, wierd, and unsettling... I must check into this ASAP. If it is indeed broken, I would think it obvious for the LAME crew to either fix it or circumvent it. Thanks for the heads up. This was fixed in 3.93.1, as mentionned in the history.html Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Annoyance: version.c doesn't support displayingthe full version number?
Paul Roberts a écrit : If there was no change to the code, how come there are 3 fixes in the history? preset medium added to the dll interface fix for abr/cbr presets fix -q0 switch A decision on whether to report the true version sounds like a no- brainer to me. Of course it should! And the alpha/betas status too. Well, you are right, there were some fixes in 3.93.1. We had to use 3.93.1 because there was already some 3.94 alphas floating around, and so we were unable to use 3.94 as a version. As the fixed 3.93 was quickly released, we decided to just use 3.93.1. As Alexander explained, we do not plan to use sub-versions. We had to in this case, but we would really like to avoid this. Anyway, your patch is there, and if in the future we encounter a case where sub-versions are needed, we will consider it, although our intent is to avoid such situations. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] [PATCH] to LAME to convert RIFF LIST tags to ID3tags
Charlie Lenahan a crit : 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 your submission. This should be included soon into Lame. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Lame genre bug (annoyance).
Adam Luter a écrit : The problem is that lame is very stubborn about setting the genre. If you specify an invalid genre, lame never falls back on a default (such as other). Below is the minimum changes necessary to make lame work more cosistantly Thank you for your report. This will be included soon. Regards. -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Lame genre bug (annoyance).
Alexander Leidinger a écrit : The problem is that lame is very stubborn about setting the genre. If you specify an invalid genre, lame never falls back on a default (such as other). I consider this a feature... if I make a mistake by specifying an not existing genre I want to know about it. Gabriel, do you insist to fix the genre or should I try to get some time to fix year and track number? I do not insist on using a default value in case of misspelling. I thought that at least for genre it could be a good idea, because it is easy to do a misspelling. If you want to change a little the tagging functions to properly display and return an error, I am ok with it. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [mp3encoder] Re: LAME and CRC
Alexander Leidinger wrote: I've been trying, but don't really understand enough to rip out the right pieces of LAME for this task: Take an MP3 file with CRC turned on, but incorrect checksum information and either disable CRC or recompute the checksums correctly, and make the changes without deencoding and reencoding the file. Any hints on how to do this? Is this a feature of LAME already that I can't find? The first point is that this could be an error in the stream. In this case, updating the crc might be a bad idea. There is one case where this would need to be done: old Blade files. In earlier versions, Blade was computing a wrong crc (like the iso code), and so if you decided to add crc protection, this one was wrong. I remember that when this issue was corrected in Blade, there was also a program posted on the Blade homepage to do this specific correction on already encoded files. Regards, -- Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] LAME on PocketPC
Michael Niemeck wrote: Recently got my Compaq IPAQ PocketPC, which - supposedly - sport a 400 MHz Processor. Since LAME is said to faster than real time on a PII 266 at highest quality mode I decided to give it a try. To my horror, encoding a 2 second chunk of raw PCM data takes up 40 seconds, and even at lowest quality needs at least 4 seconds. Well, the most important problem is that you probably do not have any floating point unit on your processor. Emulating floating point instructions is very time consuming. To speed up lame, you might want to use -f and -m m in order to use fast mode and mono. I think that some people on this list tryed to port lame code to fixed point. Perhaps they might give you some indications. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] LAME on .NET
Jon Skeet wrote: Has anyone tried to convert LAME to .NET at all? I was wondering whether it might not be an interesting project, partly for performance comparison purposes I'm sorry but you will not gain any performance enhancements by converting Lame to CLR byte code. If you just mean compiling it under visual studio .net (aka visual c++ 7), you will just speed things up by about 5% compared to visual c++6. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Fixed pOint Psychoacoustic model
The dynamic range is so high that sometimes even the double precision(48 bits) arent enough.. You could store mantissa in one integer and exponent into another one. This will probably be more than enough regarding dynamic range. The drawback is that in this case you are creating your own datatype. You might also want to reduce the allowed dynamic range. Anyway, you will probably have to reduce quality in some way in order to reduce processor requirements. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Need help for layer-1
MPEG2 Layer 1 do differ from MPEG1 only in its multichannel feature; audio encoding for a channels are same for MPEG1 and MPEG2. ISO recommends to use psycho model 1 for both layer 1 2. Regarding Layer 3, this uses entirely different audio representation. You may have to read little more on this :). Perhaps :-) My only experience with Layer I was this wonderfull (at that time) portable DCC recorder. While we are on this topic, may I ask you why are you interested in Layer I. I am wondering about the use of this, as it seems to me that Layer II should not need much more computations. Regards, Gabriel Bouvignewww.mp3-tech.orgpersonal page: http://gabriel.mp3-tech.org
Re: [MP3 ENCODER] Need help for layer-1
I got the Layer-2 code from Lame. You probably means that you downloaded dist10.tzg, as Lame doesn't include layer II code But the problem with the ISO code is that, It doesnot work for MPEG2-Layer1. You've got a good point here. I am assuming that you are interested in the low sampling frequencies part of mpeg2 and not the multichannel one, as dist10 already includes the multichannel part for Layer II. You might want to check TooLame, as Layer II encoder: http://mikecheng.d2.net.au/ Regards, Gabriel Bouvignewww.mp3-tech.orgpersonal page: http://gabriel.mp3-tech.org
Re: [MP3 ENCODER] Xmms player for RedHat 8.0
I've discovered that Fraunhoffer was able to force ReadHat software to remove the mp3 decoder from the xmms player. So they distribute a player with suport to Vorbis only and the source dosen't contain the mp3 decoder. I was able to move the same plugin from a Mandrake and make it work on a RedHat. FhG did not forced RedHat to remove anything. It is only the decision of RedHat. Moreover, as you pointed out, RH is not selling the RH distribution (that could include mp3 decoding), but only selling support. So under the current mp3 licensing terms, they would not be asked to pay for it. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] LAME feature request
This is easy enough under *nix to implement using return codes. Using the lame binary compiled for dos, there is no option to cause LAME to delete the output file if an error is encountered. Speciffically, the error i am getting that I would like this for is Error reading input file Under dos you can can test the value of ERRORLEVEL in a batch file. I am not sure, but I think that this might work. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Proper way to encode only 1 ch
I'd like to encode left and right channel into two seperate mono MP3s. Currently I use scale-l and scale-r to achieve the effect. Am I doing it properly? Is there anyway to disregard a channel completely in LAME? Just a guess (not sure): lame --scale-l 0 -m m (for discarding left) lame --scale-r 0 -m m (for discarding right) Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Activating the LAME MP3 Codec
I recently installed a program, but whenever I run it, I get the message 'Video Not Available; Cannot Find Vids: DVDX Decoder.' I was told that downloading this LAME MP3 Codec could easily solve the problem, but I after downloading, I read in a README file that downloading Windows 98 DDK will activate the codec. I downloaded Win 98 DDK, but I can't find anything to help me activate the codec. It looks like a lot of Java-style programming gibberish. Can anyone give me a step by step walkthrough on how to activate the codec? I am sorry but I have the feeling that the error message you get has nothing to do with Lame. Lame is an audio codec, and your message is complaining about a video codec missing. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] lame -? / DOS
Could this possibly be fixed so that under DOS it goes to standard out. It is the only way to currently see the up-to-date set of flags and in DOS there is no way to see it. Standard error can't be piped or redirected so it just scrolls off the screen. Doesn't this work? lame -? lameopts.txt 21 It should redirect stderr (output 2) to stdout (output 1) and redirect stdout to lameopts.txt. It works under cmd (NT5 shell), but I do not know about command.com under DOS (is it really DOS or command.com from win95/98?) Please report status. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] ALL VESIONS BUG !!!
All Files Bigger Than Original Wave: Time Size !!! OGG MPC haven't this bug !!! This is not a bug, but a feature of the transform method used. Working on blocks of specific length, mp3 once decoded has some padding at the beginning and at the end. (same thing for Vorbis, and probably mpc) I don't know about MPC, but it is *not* true for Vorbis. Vorbis files do not have this padding. In my full original mail, I mentionned the fact that there is this gap with Vorbis due to the transform method, but that in the ogg container there is information about how to remove this gap. What it means is the technology itself features this gap. All you can do is to store the gap size along with the stream so the decoder can remove it. Lame stores the delay, so a decoder could use this info to totally remove the gaps. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Does lame support layer-1 and layer-2
Does lame support layer-1 and layer-2. Also I found that the calling part of layer-1 and layer-2 are there but the respective source files are not there. ie In the file pcm.c we have the following, ... Where can I get the respective source files. No, Lame does not support layer I or II. This is probably old code from someone who though that perhaps Lame could handle that using external libraries, like for vorbis. This code should probably be cleaned up. Btw for layer II you could try TooLame. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] time complexity of MP3 encoder
hai there, does anyone know what is the time complexity of MP3 encoder algorithm such as Lame or the Fhg? i mean what is the big O number? is it O(n), O(n2) or else? could someone tell me how to measure this up? thanx alot Encoder complexity is roughly linear related to the number of input samples. Some parts of your track might require more time than others to encode, but it will decrease after. ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Lame Encoder!
I have found that lame encoder (lame.exe) can't encode wav file that have spaces in its' filename/folder. For examples: C:\My Music\Wav 01.wav (both have spaces in folder filename) C:\My Music\Wav01.wav (have space in folder name) C:\MyMusic\Wav 01.wav (have space in filename) It is the common behaviour of win32 console applications. You have either to use the short name, or to put the filename between double quotes. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] non-portable code in lame.h - compiling on cygwin [PATCH]
- Original Message - From: Sycotic Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, December 04, 2002 11:07 PM Subject: [MP3 ENCODER] non-portable code in lame.h - compiling on cygwin [PATCH] I have been trying to include lame as an encoder for the mplayer/mencoder software, and when trying to include lame/lame.h it gives MULTIPLE parse errors, and an error about too many }'s. After a quick glance, I think I may have found the problem: incorrect #if defines. Attached is my patch that should be more portable than what is currently being used. It Works For Me(tm). Patch is for v3.93. Replacing WIN32 by __WIN32__ is likely to break other compilers.. ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
[MP3 ENCODER] Windows Media Player problem
It seems that some users encountered compatibility problems when using mp3 files created with windows media player. (not related to time indication) Unfortunately, this problem does not occur with every version of wmp, so it could be hard to solve. If you encountered such problem, please report your wmp version and your operating system version. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] suggestions for -b 96 defaults
I've been running a SHOUTcast broadcast at 96 kbps for the past year. I keep using an old version of the SHOUTcast DSP for Winamp because I want to use the Radium FhG codec; newer versions only support the LAME DLL, and that DLL's default settings at 96 kbps apparently produce disturbingly bad artifacts in the upper midrange. I'd suggest you to use the 96 kbps preset (--preset 96) with Lame 3.93. About Shoutcast I think that we should ask to have different option in the Shoutcast dsp plugin. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] --alt-preset ultimate description
Could someone please refer me to explanations of --alt-preset switches? I have searched for a long while and all I could find was broken links or flames for asking ;/ There will be in the 3.93 docs. Another thing: is it possible to pass --alt-preset's to libmp3lame? I mean e.g. for MEncoding? It will be included in the 3.93 libmp3lame. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Quality problem reencoding
I have a number of files created with lame 3.92 using the --r3mix preset. They all sound great. The problem is when I reencode them down for streaming. It doesn't matter if I reencode on the fly or reencode first. The effect reminds me of a phase shifter commonly used on a guitar. You can actually hear it here with winamp, xmms or whatever you like here: http://caroline.pop4.net:8004 The stream is 56k @ 44.1KHz - which should sound good. ... I listened to the file, and what I hear is typical of very high mp3 compression. This might be coming from the fact that you are forcing output to 44.1kHz. At 56kbps there are not enough bits available to preserve full bandwith. You have to accept some compromise, that is trading some bandwidth against artefacts. I would suggest you to try lame --alt-preset cbr 56. Listen to the result, it is very likely to be way better... Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] 3.92 bug on win98SE
I tried yet another version of Lame 3.92 (the one on Gabriel's site Lamewin32.exe and it worked with MMX on my VIA) So what was wrong with the two other versions: So this is a compiler issue. PS the one that worked was linked here: http://www.goldwave.com/release.html I know it may look like a dumb question to you, but why is it said on the page above to copy manually LAME_ENC.DLL in C:\Windows\System if it works without it? Is it just for the GOLDWAVE program to function? Yes, this is just for Goldwave, although copying the dll into the Goldwave directory would probably also work. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] 3.92 bug on win98SE
I can't run LAME 3.92 on my system. I tried two versions, and they act the same with EAC or RazorLame. LAME 3.91 works fine. Are you using a Via/Cyrix/Ibm processor? Yes, VIA: http://www.baber.com/baber/411/pcchips-m787clr.htm Is that the problem? Yes, there is a problem with Via processors. Some code that is working fine on Intel/Amd is not working on such processors. You can add --noasm mmx to your command line. This will disable MMX optimizations and allow you to run Lame. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] GSM speech audio test
I'm using described setting, is there anyone who could produce better result for GSM speech, please? Lame --alt-preset 16 -m m Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] RE: LAME on DSP
There's some fixed point reference code which could probably be compiled for the TI device. It's called shine... it doesn't have any psycho-acoustic model Yes, there is Shine code available for fixed point. It could be a good start, but please do not consider it as reference code. It is more an example code with some potential bugs... Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Performance of Lame on Pentium III 500
On Thu, Jul 18, 2002 at 09:48:53AM -0700, RSRamesh wrote: Hi all, Is there a performance measurement of Lame on PIII 500? I am looking if Lame on PIII 500 can achieve 3x to 5x encoding speeds or not. You probably won't achieve such speed with --alt-preset standard. However it is very likely with abr/cbr With --alt-preset standard, I'm reaching about 1x on my Duron 750. But on my laptop PIII 1GHz, I'm nearly encoding at an average 2.5x with the same settings. For --alt-preset standard, you might want to try --alt-preset fast standard Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Fwd: LAME on a DSP?
Hello, I represent a group of poor students looking for an audio compression algorithm that will work for real time (or perhaps close to) encoding of an audio stream on a texas instruments 54xx series DSP (5416 being used for development). Are you aware of LAME being used for any such thing? I am not aware of such a port already done. You might want to try with Shine. There has already been a porting project of Shine to dsp by a group of students, so perhaps you might contact them. As there is also a fixed point port of Shine, it might helps you. On the other hand, Shine's quality is much lower than Lame. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
It is on purpose that the INFO tag is also written on cbr files. This is not a bug. Could you explain the purpose? It's not immediately apparent to those of us not well versed in the inner workings of the MP3 encoding process. This tag stores some information about encoding parameters, encoder delay, It allows you to know some parameters used for encoding, and could allow a totally gapless playback with proper use by the decoding software The problem is that this tag as to be written after encoding, so when encoding is finished the programmer has to call a specific function. Unfortunately it seems that the dll internal doc was not updated, and so so programmers didn't called this finishing function. In order to understand a few of the advantages, you could try using Encspot on a such a file. Then select Lame tag on the right click menu... Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Lame Info tag and gapless playback (was: Problem with Lame 3.92...)
Could you point us to some specification on how to write/adapt a decoder to do this? I'm guessing that somewhere in the Lame info tag there's a field indicating how many samples/frames/granules to omit from the start and end of the file - is that correct? http://users.belgacom.net/gc247244/extra/tag.html ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Problem with Lame 3.92 dll and Sony ZS-X3CP Boombox
Hi Steve, The problem was that the initial VBR tag (all zero's) was inserted into the MP3 file for CBR files, so when the beWriteVbrTag function was not called at the end of the encoding process you end up with an empty frame at the beginning of the MP3 file. It is on purpose that the INFO tag is also written on cbr files. This is not a bug. ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Fake frames
I'm currently writing a simple tool to convert MP3 (and later MP2 and MP1) to correct WAV files (with the exact bitrate, even for VBR files) that could be muxed with video accurately... I was thinking that it was already the case with the acm codec. Could you explain limitations of your acm codec please? But now I have a problem with the last frame that contains LAME at the same position (seems like). Is there any documentation on this frame ? I guess it doesn't contain audio. Is the LAME data always at the same position ? There is audio in this frame. The LAME string should only be some padding when in the last frame there is remaining space after audio encoding. Moreover you could check the info tag which indicates encoder delay and padding for the file in number of samples. Bye, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Re: 417 byte header offset, why? (Chris Holt)
I looked at what little documentation we have, and I think this is actually our fault - not the application. I have a question: why not calling lame_mp3_tags_fid in the flush_buffer function. As the flush buffer function is always called, perhaps it would prevent people from not calling mp3_tags_fid. Also a suggestion: perhaps we sould write a valid xing/info tag with an empty seek table at the beginning instead of just 0 padding? This way if mp3_tags_fid is not called the entire information won't be present, be the tag will still be valid. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] 417 byte header offset, why?
Inspecting the files with a Hex editor and File Info function in Winamp, I discovered that if Lame generates no ID3 tag, or a v1.1 tag only, it pads the first 417 bytes of the file with zeros. This is the space reserved to write the info/vbr tag. This tag should be written after encoding is finished. The problem might be that the front-end that you are using to encode doesn't properly call the needed function to complete this tag after encoding. So I set about looking for a switch to perhaps discontinue this feature (assuming it is a feature) but had no luck. -t Only when it sees a bunch of zeros at the start of the file does it get rude and display Not MP3. Might be an indication that your player is broken. Compliant mp3 players should skip unrecognized data. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Generated files in CVS (was: compiling lame 3.92 with gcc 3.1)
I don't have problems with removing the generated files from CVS (I know how to use auto*). But as long as there's no majority of the people with write access to the LAME CVS repository which wants to have them removed they will stay there. As a cygwin user, for wich packages are often outdated, I'd like the generated files to stay in the cvs repository. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] MP3' Tech: www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] MPEG frame lengths and time slices
I'm not sure, but I believe MPEG1 L1 and L2 only has frames of 1024 samples. 1152 Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Fwd: Clicks pops with Lame at MP3 devices
| | (Roadstar PCD-3245MPT) I get a lot of clicks pops scattered through | * --nores I think that this option would be out. With this option pops are out, but quality is much lower. Does this answer means that with --nores there are no more clicks? (btw I wasn't suggesting options for encoding, but only to help testing) But the following option is the right choice: | * --strictly-enforce-iso I'm sorry bu I don't really understand. Does this option effectively remove the clicks? And if pops occurs, then try | * -B 256 or lower value. Dont miss specify -b value and -F option!!! The curent problem is very unlikely to be a problem with small frames, so -b or -F won't help testing. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] LAME 3.91 adds a blank frame
MP3 files encoded with LAME 3.91 don't start with a real MPEG frame, but with a block of zeros the exact length of a frame (for CBR). This is not a problem for a decoder since it will ignore that frame, but I belive is a bug anyway. Besides, for calculating the duration of the file, this adds aprox 26ms at 44100Hz. This didn't happen with version 3.88 Beta. It's not a bug at all, and is made on purpose. The first frame includes some usefull info about encoding parameters. The best way to deal with it would be if the decoder was ignoring this one. As an example, if you decode with Lame --decode, Lame will ignore this frame. Regards, Gabriel Bouvigne www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] [OT] ISO Layer 1/II Absolute Threshold tables - Puzzled..
These tables (ISO Psychoacoustic Model) are built by taking values from optimized encoders used in MPEG listening tests. Perhaps the one in AAC demo code is optimized, but if the one of Layer II is the same as the Layer III demo code, then it's quite bad. In Lame it was first replaced by the so-called Painter Spanias formula, wich is a great improvement. Later it was replaced by another formula wich was improving for 15 kHz, but produced quite similar results for lower freqs. Have a look at utils.c, the ath curves are there. Regards, Gabriel Bouvigne www.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] [ot]patent issues and open source
Where did you get the information that source code is fully legal? The source code itself doesn't do anything. It's just a written description of something. The description of a patent is publicaly available, as it's the principle of patents. So another description is as legal as the patent itself. But I might be wrong as I'm not a lawyer. Either Christina Bonner (current licensing coordinator for AAC ) or her predecessor (who also send me a nice letter in the past) never contradicted me on this point. Regards, Gabriel Bouvigne www.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] [ot]patent issues and open source
However, I do not provide binaries and I state in the readme Please note that parts of this software can be under patent right restrictions and thus cannot be used freely in some countries., but I got a letter about patent infringements which demands to stop all distribution of software. You can definitively publish source code only. I received the same kind of letter from Dolby about AAC source code, explaining that they could even sue me. I responded back that source code is fully legal, and that I'll never remove the source code. It was several months ago, and I didn't heard back from them. Regards, Gabriel Bouvigne www.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
[MP3 ENCODER] Re: MS Stereo
E. Zwicker: psychoacoustics, facts and models. Let me elaborate just a little on this tonality estimation. First of all, why do we need tonality estimation? We need it because a non-tonal sound generates more masking than a tonal one, and thus we need this estimation to compute the ammount of masking. Gpsycho: based on the ISO model2 demonstration. It uses predictability. If amplitude and position of a sound can be accurately preticted from the 2 previous granules data, then the sound is considered tonal. It is a good idea, but the problem is that it can't detect the tonality of the sound before the 3rd granule where the sound is present. So the 2 first granules are wrongs. It's a little like the ISO short block estimation, were iso model needed data from previous granule, and then was switching 1 granule too late. Perhaps this could be fixed by doing tonality estimation of further 2 granules, and when a sound is detected as tonal, mark it as also tonal in the 2 previous granules. (as obviously it's already tonal since 2 granules) The second problem is that in the case of a tonal with rapid change in frequency, like a sine sweep, we miss it everytime. Nspsytune: based on the same kind of ideas as the ISO model1 demonstration. (in the case of nspstytune I'm not really sure, I hope that Naoki will correct me if I'm wrong) It uses peak detection. If a freq amplitude is higher by a threshold than its neighbours, then it's considered as tonal. There is no delay like in gpsycho, but if several tones are close enough, it will miss them (could it be the case with Fatboy?). So the 2 methods are differents, and right now none of them works perfectly. Perhaps a corrected (like suggested) method one, or a combination of the 2 methods would be accurate enough... Btw I'd suggest you to have a look at references on the Lame website, I added references to papers about this tonality estimation. Regards, Gabriel Bouvigne www.mp3-tech.org - Original Message - From: reinhard To: [EMAIL PROTECTED] Sent: Monday, January 28, 2002 10:58 AM Subject: Re: [MP3 ENCODER] MS Stereo One of the biggest differences between l3psycho_anal_ns and l3psyco_anal is exactly what you are asking about - how the estimate the tonality index. One is a tweaked and cleaned up version of the MPEG1/2 recommendation: the predictiictability of the energy in each band over several granules. I believe it comes from thesis work of one of the creators of MP3. The other is based on how peaked the spectrum is, and uses data just from a single granule. Naoki wrote it based on data in Zweicker's book. Zweicker's book?? would you tell me the name of the book or more information about the l3psycho_anal_ns Keep in mind that all the models are very crude estimates, and the output should be considered as a rough guide to the noise shaping algorthims rather than absolute truth. ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] MS Stereo
E. Zwicker: psychoacoustics, facts and models. Let me elaborate just a little on this tonality estimation. First of all, why do we need tonality estimation? We need it because a non-tonal sound generates more masking than a tonal one, and thus we need this estimation to compute the ammount of masking. Gpsycho: based on the ISO model2 demonstration. It uses predictability. If amplitude and position of a sound can be accurately preticted from the 2 previous granules data, then the sound is considered tonal. It is a good idea, but the problem is that it can't detect the tonality of the sound before the 3rd granule where the sound is present. So the 2 first granules are wrongs. It's a little like the ISO short block estimation, were iso model needed data from previous granule, and then was switching 1 granule too late. Perhaps this could be fixed by doing tonality estimation of further 2 granules, and when a sound is detected as tonal, mark it as also tonal in the 2 previous granules. (as obviously it's already tonal since 2 granules) The second problem is that in the case of a tonal with rapid change in frequency, like a sine sweep, we miss it everytime. Nspsytune: based on the same kind of ideas as the ISO model1 demonstration. (in the case of nspstytune I'm not really sure, I hope that Naoki will correct me if I'm wrong) It uses peak detection. If a freq amplitude is higher by a threshold than its neighbours, then it's considered as tonal. There is no delay like in gpsycho, but if several tones are close enough, it will miss them (could it be the case with Fatboy?). So the 2 methods are differents, and right now none of them works perfectly. Perhaps a corrected (like suggested) method one, or a combination of the 2 methods would be accurate enough... Btw I'd suggest you to have a look at references on the Lame website, I added references to papers about this tonality estimation. Regards, Gabriel Bouvigne www.mp3-tech.org - Original Message - From: reinhard To: [EMAIL PROTECTED] Sent: Monday, January 28, 2002 10:58 AM Subject: Re: [MP3 ENCODER] MS Stereo One of the biggest differences between l3psycho_anal_ns and l3psyco_anal is exactly what you are asking about - how the estimate the tonality index. One is a tweaked and cleaned up version of the MPEG1/2 recommendation: the predictiictability of the energy in each band over several granules. I believe it comes from thesis work of one of the creators of MP3. The other is based on how peaked the spectrum is, and uses data just from a single granule. Naoki wrote it based on data in Zweicker's book. Zweicker's book?? would you tell me the name of the book or more information about the l3psycho_anal_ns Keep in mind that all the models are very crude estimates, and the output should be considered as a rough guide to the noise shaping algorthims rather than absolute truth. ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] 2k+2 (was: no subject)
Happy new year to everyone. -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] MP3' Tech: www.mp3-tech.org personal page: http://gabriel.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] DLL bug (bis)
Here are the debugging info I have when I encode to 44kHz/96 kbps and I get a 32kHz/96 kbps file/stream : ... 1161 3866.37668017 [288] Disable Resorvoir =1 Is this one on purpose? Seems strange to disable bit reservoir ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Lame recognition
They don't give reasons why they use LAME. But I'm really curious to know. I'm not sure if it's really legal to use LAME for commercial selling of the encoded files (because of the patents on MP3). They're probably using Lame because it's saving money compared to FhG. For sure it's legal to use Lame commercially if they payed the licence fees. ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] MP3 bitstream
1. The ISO 11172-3 standard says that the number of samples in layer 3 should be 1152. When I encode a single channel file lame sets the framesize as 576. Is this an error or does the standard specify the size for dual channel audio? It seems that you are encoding MPEG-2 frames. Those frames have only 1 granule, so they are only 576 samples. The sample rate of MPEG-2 is half the MPEG-1 sample rate. Regards, Gabriel Bouvigne www.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Timeshifting after decoding
Is there a way to predict this timeshift? Does anyone know if it's a variable based on encoding or constant? It's because of the encoder delay. Now (3.90) Lame writes a kind of header into the first frame, and one of the fields of this header is the encoder delay. ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Timeshifting after decoding
Given that could a well written decoder strip it off and give time and length coherency between source and result? Yes, it's perfectly possible. However this tag is quite a new thing, and I think that right now there is no encoder that uses (yet) this info. ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] The Pause That Documents
I sincerely hope that before 3.90 is promoted to beta there be a pause to update and consolodate user documentation ... It is very frustrating to try and find out what Lame can do and how to do it to just find cryptic flags that if described at all are usually done so in jargon meaningful only to people working on it. Totally agree on this. There will be an updated html doc (unless I don't have the time, I hope to do it this week). Look at the current html doc. Yes, there is a plethora of switches, but only those described in the basic switches are really needed for the average Joe (including me usually). As an example, I only use lame -mj -V1 for my encodings, nothing else. I use only the other switches for experimentation. Do you think that the basic switches section is too complex? Regards, Gabriel Bouvigne www.mp3-tech.org ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
Re: [MP3 ENCODER] Berkeley multimedia workload
URL? http://golem.cs.berkeley.edu/~slingn/research/publications/mm_workload.htm ___ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
