Re: [MP3 ENCODER] Why it's still a patch against iso dist10 ?
hi, I'm asking myself why the source of Lame 3.70 is still a patch against the ISO-Code. In the history there is a remark that the last ISO-Code is removed from LAME - So it would be much more simple to distribute a plain sourcecode instead a patch, or am I wrong ?! A+ Christian Actually, LAME 3.70 still contains ISO code. That remark is for the not-yet-released LAME 3.80 beta. But I think you are right, and we can drop the patch distribution model for all future distributions :-) Of couse this doesn't change the fact that to distribute programs based on compiled versions of LAME may require a patent license in some contries. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] [aldov@ptt.yu: MP3 and hi-frequences]
Here's an interesting message I thought should be posted to the mp3encoder list: --- Start of forwarded message --- From: "Aleksandar Dovnikovic" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: MP3 and hi-frequences Date: Fri, 14 Apr 2000 21:00:41 +0200 Hello. First of all, congrats on a great job you guys are doing with LAME. I just wanted to point out the problem that all MP3s (more or less) have with high-frequencies (16kHz). Interesting thing is that this problem is practically in the left channel - you can hear frequencies over 16kHz being "echoed", "swirled" in left channel. Now LAME indeed does the best job with these frequencies, FhG Xing do pretty worse while Bladeenc is horrible. When I first discovered this, I thought it had something to do with joint stereo, but it didn't. I mean, if you can get proper hi-freq. encoding in the right channel, why can't you do it also in the left? Is it encoder using some intensity stereo for those frequencies? Why doesn't stereo mode help when the encoder then encodes channels separately (but with different bitrates). Maybe you should try adding an option in LAME that will encode everything in 16-20kHz range in dual mono...? FhG AAC doesn't have these problems with hi-freq. Also since LAME has worse pre-echo detection then FhG MP3 (the only thing in which FhG still holds the edge over LAME) have you thought of reverse engineering mp3enc31.exe - I know it can be pretty time consuming but most of you LAME guys are quite experienced so you might be able to extract what algorithm FhG uses... Your comments will be very much appreciated. Keep up the good work. --- End of forwarded message --- -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] [aldov@ptt.yu: MP3 and hi-frequences]
From: "Aleksandar Dovnikovic" [EMAIL PROTECTED] with high-frequencies (16kHz). Interesting thing is that this problem is practically in the left channel - you can hear frequencies over 16kHz being "echoed", "swirled" in left channel. Now LAME indeed does the best job with This may be winamp-related problem. Nitrane decoder is buggy, and I discovered this left channel distortion when I tested -Y switch with lame 3.50 or so. I like to know, what decoder Aleksandar uses. Slavo -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] definition of kbps
networks are measured with k = 1000. storage is measured with k = 1024. this is how it has traditionally been. jack. On Mon, 17 Apr 2000, Shawn Riley wrote: Is 1 kilobit per second supposed to be 1024 bits per second, or 1000 bits per second? Shawn -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] definition of kbps
In mp3 audio it's 1000 bits per second, in Microsoft's media formats it's 1024 bits per second mark told me it was so they could say they could say they took the same amount of space (128kbps) even though they squeezed more data in there. the cheaters. jack. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] definition of kbps
From: Jack Moffitt [mailto:[EMAIL PROTECTED]] networks are measured with k = 1000. storage is measured with k = 1024. this is how it has traditionally been. It seems to be quite common to use the prefix "K" to refer to multiples of 1024, and "k" for mutliples of 1000, but I don't know if this is formalised anywhere. Similarly "B" for bytes and "b" for bits... 64KB of memory vs. 64kbps MP3. -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] definition of kbps
Mathew Hendry wrote: From: Jack Moffitt [mailto:[EMAIL PROTECTED]] networks are measured with k = 1000. storage is measured with k = 1024. this is how it has traditionally been. It seems to be quite common to use the prefix "K" to refer to multiples of 1024, and "k" for mutliples of 1000, but I don't know if this is formalised anywhere. Similarly "B" for bytes and "b" for bits... 64KB of memory vs. 64kbps MP3. There is a ISO draft or proposal or something that says : bk bM bG , as binary kilo , binary mega etc are powers of two ( 1024 etc... ) b is short for byte ( I'm not sure about this ) bit should not be abbreviated , unless it is clear from context that it is bit and not something else ( byte for example ). B is already used for Bell. This document is on the web , but I forgot the URL :-( david -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] lame and MPEG 1 or 2
Hello, I am trying the ripper/encoder CDEX 1.20, with the Lame (3.38 engine) encoding option. I surprisingly observe large file size differences depending if I select MPEG1 or MPEG2 (30% smaller). So: -I don't know exactly the differences between MPEG1/MPEG2 layer 3, but I though they were very small ? -I didn't find how to select MPEG1 or MPEG2 by using the command line version of Lame (I tried 3.70) Many thanks for your help, Pierre Hugonnet -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] [aldov@ptt.yu: MP3 and hi-frequences]
Yes, that post was interesting enough. I started working on it right after I got it! I took a stereo wave file [a difficult one, which has frequencies just *jumping* around 20Khz!]. opened it with CoolEdit, deleted one channel and pasted the other channel over it. So, the two channels were 100% indentical. I encoded it with BladeEnc, Xing, LAME Encoder 3.70 and MP3Enc. All encoder but BladeEnc, processed the two channels almost identically. However, on true stereo mode LAME did encode the two channels *slightly* differently. The difference is VERY subtle. Blade did a horrible job. The stereo channels were quite different and produced muffled sound in both channels. That seems like the worst encoder anyway. But in true stereo mode, should not be the both channel 100% identical, where the source is so? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
Hi peeps, I know this is MP3-encoder but I couldn't find any place more suitable to post the results of some decoder testing I've been doing over the last couple of days. I took a fairly complex track (Pat Metheny's Imaginary Day title track in fact) ripped from CD at 44.1khz 16bit stereo, and encoded it using Fraunhofer's MP3Enc v3.1 to a 256kbit MP3 file using the '-qual 9' setting. I then proceeded to decode the track using various decoders. The decoders I tested were l3dec v2.74, Sonique aE4 (from v1.51.0) and two Winamp decoders, the first from v2.2 (the first release with the Fraunhofer codec) and the second from v2.6 (Nitrane). I then compared the output WAV files to discover any potential differences! To compare the audio files, I found a suitably complicated 10-second portion of audio in the original WAV file, then identified by inspection a suitable reference point at the start of this section, which turned out to be a particular peak in the waveform that was clearly identifiable. Using CoolEdit 2000 I marked the corresponding sections in the decoded WAVs to the exact sample. This allowed me to subtract one of the WAVs from the other and thereby do a direct comparison. My first discovery was that out of the four WAV files I had, three were almost exactly identical. The decoded audio from aE4 and the Fraunhofer WinAmp codec was byte-by-byte identical with that from l3dec apart from the occasional 1-bit quantization error (v occasional - about 2 or 3 a second I'd guess). However the Nitrane WAV, whilst identical in almost every respect and certainly identical below 13kHz, showed differences in the 13khz-16khz band. These differences appeared in the subtracted audio as single isolated spectral components, of very short duration (perhaps 0.05s) and constant frequency. They were distributed quite evenly between the left and right channels, maybe 5 per channel per second. Each had an amplitude of perhaps -60db. The question now was whether these were a) components missing from l3dec's output; b) components missing from nitrane's output; c) components present in both but at different amplitudes or d) something else. A little detective work was in order. I put CEP 2000 into spectral view and captured the spectrums into Paint Shop Pro, where I could subract then from each other as images. What I discovered was that the components were always present in both, but were either at different amplitudes, or at slightly different positions - the nitrane components were roughly 50/50 too far ahead or too far behind the l3dec components. This is clearly a bug, either in fraunhofer's code or nitrane's code. I could not hear the differences (untrained ear) nor could I verify which was more 'correct' to the mp3 format since I know nothing of this. My immediate conclusion would be that Nitrane has a bug that is causing these errors. However, since Nullsoft have licensed Fraunhofer's mp3 decoding code already, for version v2.2, and since the v2.6 Nitrane decoder's about box still has a panel crediting the mp3 decoder license to Fraunhofer, why would Nullsoft exchange a perfectly good piece of Fraunhofer code for Nitrane code that produces these bugs? Are these bugs actually original bugs in the ISO implementation upon which presumably Fraunhofer's code is based? Are these differences worry-worthy? Hope this is of interest to somebody. I also did some encoder quality tests and discovered that I could not coax MP3ENC to encode the 16-22kHz band particularly well - it would occasionally code components up to 20kHz but in places where it mattered, for example drum attacks, it seemed not to bother. LAME 3.70 did much better in this area. As I can hear some components above 16kHz and since LAME is about 10 times faster on my machine I'm sticking with LAME. Nice work guys :) If anybody's really interested I'll put up some pictures of the results somewhere. The basic conclusion is: there is no major difference between any of the MP3 decoders out there, except to say that that WinAmp's EQ sucks bigtime. They all have the same frequency response. Matthew -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
Hi Matthew. Interesting analysis. Just one question. What do you mean by WinAmp's EQ sucks bigtime. They all have the same frequency response. Ross. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] vbr problems with mpg123?
I was pretty excited to get lame 3.70 since the older releases crashed my box. :) I encoded an album with lame -v -h -p -b 128 (using the notlame binary) and everything went well until I tried to play it back with mpg123... Here's what I got: Playing MPEG stream from 01-Sometimes.mp3 ... MPEG 1.0 layer III, 64 kbit/s, 44100 Hz stereo big_values too large! mpg123: Can't rewind stream by 505 bits! big_values too large! big_values too large! big_values too large! big_values too large! big_values too large! big_values too large! big_values too large! big_values too large! big_values too large! big_values too large! big_values too large! big_values too large! mpg123: Can't rewind stream by 90 bits! Blocktype == 0 and window-switching == 1 not allowed. Playing MPEG stream from 02-Hear_Me.mp3 ... MPEG 1.0 layer III, 64 kbit/s, 44100 Hz stereo mpg123: Can't rewind stream by 60 bits! Blocktype == 0 and window-switching == 1 not allowed. however, xmms seems to play it just fine - it's been a while since I've played with this stuff, but I thought that mpg123 was supposed to handle vbr mp3s... so I'm not sure what the problem is. Thanks! I appreciate all your work! -Eric -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] vbr problems with mpg123?
On Tue, 18 Apr 2000 22:51:52 -0500, Eric Sandeen wrote: I encoded an album with lame -v -h -p -b 128 (using the notlame binary) and everything went well until I tried to play it back with mpg123... try using the -y commandline switch of mpg123.. if I remember, this is what I had to do.. Paul -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
