Re: [MP3 ENCODER] MP3 encoding speed : LAME XING
You're right Mark, compared to Lame 387 MMX --abr 128 Xing is only two times faster Bo) Regards, Wim Speekenbrink - Original Message - From: "Mark Taylor" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, September 30, 2000 6:19 AM Subject: Re: [MP3 ENCODER] MP3 encoding speed : LAME XING | | | Well, I just compared speed: Xing is about 4 times faster than Lame in VBR | mode. | | Regards, | Wim Speekenbrink | | | Compare to "lame --abr 128". | I bet Xing's VBR mode is much closer to LAME's ABR than LAME's VBR. | | Mark | | -- | MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) | -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] wav/riff header support and preciseness of lame
Hi, I have used lame for 1 day now, and I really like it, except for the following 2 'issues': - Lame does not support outputting to a wav file with mp3 compression (a mp3 with wav header). Since these files are needed for programs like virtualdub (for combining video and audio), this feature would make lame even more complete. - 'Preciseness' of lame: when I encode a wav file with a length of 97 minutes and 4 seconds, the resulting mp3 is only 97 minutes and 3 seconds. This impreciseness is much smaller than the fraunhofer codec's as found in AudioActive Production Studio 2.04 (about 5 seconds shorter), but nevertheless unwanted. For perfect video and audio combining, the tracks should be exactly the same length. I am no programmer and don't know how to implement/fix these issues, and therefor I try to get attention for these issues.
Re: [MP3 ENCODER] wav/riff header support and preciseness of lame
- Lame does not support outputting to a wav file with mp3 compression (a mp3 with wav header). Since these files are needed for programs like virtualdub (for combining video and audio), this feature would make lame even more complete. Don't use LAME - use CDEx with its LAME plugin: http://www.cdex.n3.net/ I think the downloadable version comes with a slightly older version of lame. For the newest version of the LAME plugin, try: http://www.chat.ru/~dkutsanov/ - 'Preciseness' of lame: when I encode a wav file with a length of 97 minutes and 4 seconds, the resulting mp3 is only 97 minutes and 3 seconds. This impreciseness is much smaller than the fraunhofer codec's as found in AudioActive Production Studio 2.04 (about 5 seconds shorter), but nevertheless unwanted. For perfect video and audio combining, the tracks should be exactly the same length. I've found LAME to be perfectly precise - i've made AVIs with LAMEd soundtracks well over 3 hours in length in which the sountrack has maintained perfect sync with the video. Perhaps the programmes you're using to find the length of the individual files are incorrect. The only way i'd test for incorrectness would be to test with an AVI file - if the video and audio still sync after three hours, then it doesn't matter what some programme tells me - I know that it works. David -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] wav/riff header support and preciseness of lame
- Lame does not support outputting to a wav file with mp3 compression (a mp3 with wav header). Since these files are needed for programs like virtualdub (for combining video and audio), this feature would make lame even more complete. I agree about this. I'd also like to see this feature in Lame. It would be nice if someone would add a --l3wav option to Lame (note: this shouldn't be too difficult as it's already implemented in cdex) - 'Preciseness' of lame: when I encode a wav file with a length of 97 minutes and 4 seconds, the resulting mp3 is only 97 minutes and 3 seconds. This impreciseness is much smaller than the fraunhofer codec's as found in AudioActive Production Studio 2.04 (about 5 seconds shorter), but nevertheless unwanted. For perfect video and audio combining, the tracks should be exactly the same length. How to be sure that it's not a decoder problem? It seems that some decoders report false durations, even for cbr encoding. Regards, -- Gabriel Bouvigne - France[EMAIL PROTECTED]mobile phone: [EMAIL PROTECTED]icq: 12138873 MP3' Tech: www.mp3-tech.org
Re: [MP3 ENCODER] wav/riff header support and preciseness of lame
Gabriel, I don't think is very complicated to add the CDex Riff-Wav code to Lame front-end, maybe later this week I have some time to implement this Albert - Original Message - From: Gabriel Bouvigne To: [EMAIL PROTECTED] Sent: Sunday, October 01, 2000 3:42 PM Subject: Re: [MP3 ENCODER] wav/riff header support and preciseness of lame - Lame does not support outputting to a wav file with mp3 compression (a mp3 with wav header). Since these files are needed for programs like virtualdub (for combining video and audio), this feature would make lame even more complete. I agree about this. I'd also like to see this feature in Lame. It would be nice if someone would add a --l3wav option to Lame (note: this shouldn't be too difficult as it's already implemented in cdex) - 'Preciseness' of lame: when I encode a wav file with a length of 97 minutes and 4 seconds, the resulting mp3 is only 97 minutes and 3 seconds. This impreciseness is much smaller than the fraunhofer codec's as found in AudioActive Production Studio 2.04 (about 5 seconds shorter), but nevertheless unwanted. For perfect video and audio combining, the tracks should be exactly the same length. How to be sure that it's not a decoder problem? It seems that some decoders report false durations, even for cbr encoding. Regards, -- Gabriel Bouvigne - France[EMAIL PROTECTED]mobile phone: [EMAIL PROTECTED]icq: 12138873 MP3' Tech: www.mp3-tech.org
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
I think the mp3 encoding library should do what it is supposed to do, encode pcm samples into mp3 frames. BTW, Robert and everyone, how should we treat with mpglib and lame_mp3_XX routines in frontend/get_audio.c and amiga_mpega.c ? I think these routine should be another library, and the library name should not be lame_XXX any ideas ? --- Takehiro TOMINAGA // may the source be with you! -- We have to at least try and break the old, "frozen" interface as little as possible. There are many applications which use this interface (to the static library). There are some issues related to this if the library becomes a popular shared library. However, there is only 1 application which uses LAME as a shared library, and it uses a built in feature of Linux to check the version number before running. So right now the shared library issues are moot. It is more important to get the static library working than it is to solve all issues related to the shared library. So I want to have encoding, decoding, id3tags and vbrtags in libmp3lame.a, and only one include file, lame.h. Once this is all working, then we can start on the new function call interface to LAME. When that is done, we can then schedule the old, public struct interface for removal, but it should stay around for at least a year or so. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
Mark Taylor schrieb am Son, 01 Okt 2000: I think the mp3 encoding library should do what it is supposed to do, encode pcm samples into mp3 frames. BTW, Robert and everyone, how should we treat with mpglib and lame_mp3_XX routines in frontend/get_audio.c and amiga_mpega.c ? I think these routine should be another library, and the library name should not be lame_XXX any ideas ? --- Takehiro TOMINAGA // may the source be with you! -- We have to at least try and break the old, "frozen" interface as little as possible. There are many applications which use this interface (to the static library). There are some issues related to this if the library becomes a popular shared library. However, there is only 1 application which uses LAME as a shared library, and it uses a built in feature of Linux to check the version number before running. So right now the shared library issues are moot. It is more important to get the static library working than it is to solve all issues related to the shared library. So I want to have encoding, decoding, id3tags and vbrtags in libmp3lame.a, and only one include file, lame.h. Once this is all working, then we can start on the new function call interface to LAME. When that is done, we can then schedule the old, public struct interface for removal, but it should stay around for at least a year or so. Mark So for backward compatibility we should make a wrapper library with the old interface (as much as possible) and mark this as old and outdated, to give clients the possibility for smooth migration to the new API. old clientnew clients || v| wrapper lib | || ++- | || v vv lame-enc-lib lame-dec-lib lame-hdr-lib lame-enc-lib: - lame's encoding engine - maybe with Xing's VBR header stuff if it must be lame-dec-lib - lame's wrapper to the mpg123 library lame-hdr-lib - wave header - Xing header - ID3 stuff wrapper lib - the old libmp3lame and interface Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Ogg Vorbis b2 problem encoding this sample...
Sorry to write to this board, but it was my last resort to reach the authors of the project... I wrote an email regarding this bug, and it's been already one or two weeks, no response. So as i know Monty and the other developers read this, i thought i'd share this with you... I don't know if it's already known the problem with this sample.. I don't remember where i got it, and it was a long time ago, so i don't know if sweep.wav is the original name... I made it 2 channels so vorbis could encode it.. I've tryed vorbis b2 encoder with some samples here, and the progress from b1 is huge in my opinion. But in this particular sample, it produced really strange and audible artifacts... Maybe someone knows the answer to such problem? Is this bug known by you; Monty, and the other guys working with you? The sample's at freedrive... Go to freedrive.com Login: uploadspace100 Pass: nopass Get sweep2c.wav Hoping this can help you improve the encoder. Best Regards, Machado, Bruno. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Free format
In reply to Robert Hegemann [EMAIL PROTECTED]: Second: With some (usually high) bitrates, LAME seems to mangle the bitstream. The effect is usually to hear short bursts of garbage in the left channel, but it seems to depend on the input file as well as the bitrate. Not all frames are affected. Rob, can you provide us with a short example track? I'm happy to report this turned out to be a bug in my code, not in LAME. I didn't anticipate well enough the possible resulting main_data() lengths for some of these very high bitrates. I think I've properly recalculated the maximum main_data length to be 16380 bits, since each part2_3_length is limited to 2^12 - 1. Does this seem right? I suppose a legitimate decoder might well refuse to decode a stream with main_data() lengths exceeding the 7680-bit buffer limit imposed by ISO/IEC 11172-3. My next release of MAD should have this fixed and will fully support any free format bitrate produced by LAME... with the exception of MPEG 2.5 streams. On that subject, where can I get "official" documentation for the so-called MPEG 2.5 format? Cheers, -- Rob Leslie [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] lame 3.87 encode-decode roundtrip
Please pardon the question if naive but I couldn't find the answer elsewhere... I encode the same .wav to 2 different .mp3's - first one CBR (-b256 -ms -h), second one VBR (-V1 -b128 -mj -q1). Then I decode (--decode) the 2 .mp3's back, and the resulting .wav's have different sizes, both of them different from the original one. Is this expected behaviour? Best Regards, Liviu -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib related routines (Re: modularization)
Hi Robert, This just seems like a lot of work for no real gain since all 4 libraries are samll and closely related. To build LAME we would need a ./configure setup which builds 4 different libraries. so I guess I just dont see any reason to seperate them. Special applications, like embeded encoding, will be using static libraries anyway, so they can just compile a lightweight version of libmp3lame.a. Mark So for backward compatibility we should make a wrapper library with the old interface (as much as possible) and mark this as old and outdated, to give clients the possibility for smooth migration to the new API. old clientnew clients || v| wrapper lib | || ++- | || v vv lame-enc-lib lame-dec-lib lame-hdr-lib lame-enc-lib: - lame's encoding engine - maybe with Xing's VBR header stuff if it must be lame-dec-lib - lame's wrapper to the mpg123 library lame-hdr-lib - wave header - Xing header - ID3 stuff wrapper lib - the old libmp3lame and interface Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
