Re: [MP3 ENCODER] min bitrate and bit reservoir (was: MS switching)
ETA - Estimated time of arrival. kind of obscure :) mark stephens - Original Message - From: "Frank Klemm" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 12, 2000 4:00 PM Subject: Re: [MP3 ENCODER] min bitrate and bit reservoir (was: MS switching) Another question: What is ETA? A basque terror organization? I don't found it in any printed dictionary, also not in the big webster I bought in England. But you find nearly all C keywords in it ;-) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Off Topic Advice Please
But, isn't LAME higher quality at a faster speeds? The new FhG codec at high speed isn't very good, I thought, or is there proof otherwise? To make encodes as good as LAME I though you had to set it to slow speed and wait 15 minutes. mark stephens - Original Message - From: "Mark Taylor" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, August 12, 2000 10:38 PM Subject: Re: [MP3 ENCODER] Off Topic Advice Please Musicmatch now comes with free, unrestricted MP3 encoding using the FhG codec. I think this is going to make a series dent in the amount of people using LAME under windows and Mac! Will Realaudio Jukebox even let you encode mp3 files? I would think they would encode to "real" format. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the road to next(v4.00?)
Howdy, I tried to search through all the messages related to this topic, but I couldn't find any that addressed the speed issue. Trying VBR using the lastest 3.8 CVS source, VBR is still slower than CBR. Is this still a future improvement, or do I need to set an option? mark stephens - Original Message - From: "Takehiro Tominaga" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, April 06, 2000 8:15 AM Subject: [MP3 ENCODER] the road to next(v4.00?) Hi all. I'm planning these features to merge the current LAME from my snapshot... ... 2 fast VBR code new algorithm. it is faster than CBR! ... -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mp3 vs. wma
I think that WMA is easier to listent too at lower bitrates because the distorion tends to mimick old analog recordings. Even at 160 it sounds hissy, but very acceptable because my ears are used to ignoring the distortion. IMHO WMA at 128 is as good as MP3 at 128, if only because the artifacts are easier to ignore. MP3 is superior above 128. mark stephens - Original Message - From: "Scott Manley" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, February 15, 2000 10:49 AM Subject: Re: [MP3 ENCODER] mp3 vs. wma what are your thoughts? WMA sounds very good on casual inspection, far better than mp3 at about 64kbit, probably about the same as AAC/Mpeg4 at that bitrate. But it doesnt get any better as the bitrate goes up - and there's an annoying hiss that reminds me of listening to old cassete tape. Scott Manley (aka Szyzyg) /-- _@/ Mail -\ ___ _ _ __ __ _ | Armagh Observatory | / __| __ ___| |_| |_ | \/ |__ _ _ _ | |___ _ _ | Armagh | \__ \/ _/ _ \ _| _| | |\/| / _` | ' \| / -_) || | | Northern Ireland | |___/\__\___/\__|\__| |_| |_\__,_|_||_|_\___|\_, | | BT61 9DG. | http://star.arm.ac.uk/~spm/welcome.html |__/ \=/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME in the PRESS
It is true that joint stereo can give better results, but it is also true that it is just another algorithum that can go wrong. Look at the LAME change log for example, there have been some minor bugs in JS. I think JS got a bad name from Xing and their whacked out implementation. Xing JS can introduce all kinds of phase other strange errors that other encoders never seem to have a problem with. mark stephens - Original Message - From: "Felix von Leitner" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 03, 2000 9:04 AM Subject: Re: [MP3 ENCODER] LAME in the PRESS I wonder where the myth that joint stereo would somehow adversely affect quality comes from. Was it the web pages from the BladeEnc guy? I don't know. Anyway, joint stereo does not make the signal and worse, it just allows for a better bandwidth use because on most signals the bulk of the sound is equal on both channels. With joint stereo, this part is only encoded once for both channels, so this is a good thing. ... -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME in the PRESS
I believe the fraunhofer codec in the new Musicmatch is identical to the one in Nero. I also remember reading that the new fraunhofer hi speed VBR is very shabby quality compared to the older versions. I would like to weigh in on the side of leaving VBR settings alone. LAME is different and better :) Personally, I use LAME 160 stereo for all my encodes, fast and sounds great to me. IS Xing VBR really considered good? I can hear artifacts in VBR normal/HQ simple stereo right away, and I am not very demanding. Indigo Girls, Swamp Ophelia, Song #8, Mystery. The voices warble and it is very noticeable to me. LAME 160 has no problem at all. Has anyone ever really done a good double blind test comparing Xing VBR -- Fraunhofer VBR -- LAME VBR? mark stephens - Original Message - From: "Rolf Hanich" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, February 02, 2000 7:33 PM Subject: AW: [MP3 ENCODER] LAME CRASHES / LAME in the PRESS Let me butt in at this point: Maybe you should have a look on the new Fraunhofer plugin, as used in Nero. It's very aggressively using higher bit rates in VBR (96...200 in medium quality setting, avg. about 140) and runs 8-10 faster that real time on a current CPU. The results in my opinion are brilliant. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Normalization routine?
Howdy You mentioned the limited value of normalization that only looks at peak levels to normalize, especially if there are just a couple of loud passages in a song. If you first applied peak limiting, the loud passages would be compressed to be just a little louder than the normal passages. Second, apply normalization to it to bring the loudest passage up to the maximum level. As you may know, normalization just brings the loudest portion of the wav file up to maximum level (or whatever level you specify) and adjusts everything else equally. Normalization is like turning up the volume, no dynamic range is lost. The difference between the quietest sounds and the loudest sound is the same. If you change the difference (dynamics) of the music then you are either compressing or expanding. By letting the peaks clip, you are using distortion to reducing the dynamic range of the music. Peak limiting just reduces the output for any waveform above a threshold that you set, without adding clipping distortion. AFAIK many classical radio stations use peak limiting compression during broadcast to reduce the output of the loud passages without effecting the quiet ones. POP stations tend to use broadband compression, and you can hear it during quiet passages when it sounds like someone is turning up the volume and you hear all the background noise. Of course, with todays super quiet digital equipment it isn't really that noticeable any more. mark stephens -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard A. Smith Sent: Monday, January 17, 2000 12:55 PM To: [EMAIL PROTECTED] Subject: RE: [MP3 ENCODER] Normalization routine? On Mon, 17 Jan 2000 11:03:57 -0500, Mark Stephens wrote: Wouldn't that be compression, instead of normalization? I don't really know. I don't have much experience with compressors. Will a compressor boost a quiet waveform and allow it to clip? I still have an old DBX compressor/expander box where I can choose to compress over the whole range, or set it to peak limiting mode and only compress over a certain threshold. It sounds like it might be valuable to have a routine that can do peak limiting, and then normalize the result. I don't understand what you mean by peak limiting and why it would be necessary if you are going to normalization. -- Richard A. Smith Bitworks, Inc. [EMAIL PROTECTED] 501.846.5777 Sr. Design Engineerhttp://www.bitworks.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Normalization routine?
Wouldn't that be compression, instead of normalization? I still have an old DBX compressor/expander box where I can choose to compress over the whole range, or set it to peak limiting mode and only compress over a certain threshold. It sounds like it might be valuable to have a routine that can do peak limiting, and then normalize the result. mark stephens -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Richard A. Smith Sent: Monday, January 17, 2000 10:43 AM To: [EMAIL PROTECTED] Subject: Re: [MP3 ENCODER] Normalization routine? Before I burn stuff to CD's I usually hand normalize the music with CoolEdit. It's been my experience that you can introduce quite a bit of clipping in the waveform without any noticable quality loss. In fact several of the songs ripped directly from my CD's had a suprising ammount of clipping to begin with. I doubt that any normalization routine rounding errors are going to make a perceved quality difference. The problem that I find with automatic normalization programs is that they normalize to the peak level which can still leave quite a bit of difference between a quiet song and a loud song. An intelligent normalization routine would be quite handy. To do this properly however I think you will need some sort of 2 pass procedure. 1 to run through the file and compute the scale factor and then a second pass to apply it. -- Richard A. Smith Bitworks, Inc. [EMAIL PROTECTED] 501.846.5777 Sr. Design Engineerhttp://www.bitworks.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBR digital silence bug 3.58
hmmm, on my build, with VC5, it drops almost immediatly, maybe one second into the sample. Is there a different calculation used for VC on a Win PC? mark stephens - Original Message - From: "Mark Taylor" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 21, 1999 2:57 AM Subject: Re: [MP3 ENCODER] VBR digital silence bug 3.58 Hi Mark, Which part of the sample do you hear the problem, and is it subtle or real obvious? I just tested this sample - with lame3.58, I only see the bitrate drop to below 112kbs in frames 220-245, (the last .6s) and in that section I cant hear any music. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBR digital silence bug 3.58
ack, it was winamp observations, and my playback buffer is 5 seconds. I must have imagined the audio distortion :-( Tool error, me being the tool. mark stephens - Original Message - From: "Robert Hegemann" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 21, 1999 10:35 AM Subject: Re: [MP3 ENCODER] VBR digital silence bug 3.58 Have you verified this behaviour with the frame analyzer? Or do you notice this while playing in winamp? If your observation is based on winamps display, the answer is easy. Winamp does not show the bitrate of the actual playing frame, but the one it decodes, usually a few seconds ahead. Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] VBR digital silence bug 3.58
Howdy, LAME 3.58 Counting Crows - Omaha, off the CD 'August and Everything After' The fadeout at the end of the song starts dropping to 32kbps long before it has faded to inaudable, causing noticeable distortion. Some timing tests on my K6/3-450 under NT 4.0: 3:40 song length, 2:00 160kbps, 9:00 VBR4 112kbps min mark stephens -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] BladeEnc vs. LAME at high bitrates
Howdy, if you read the LAME web page you will see how they improved LAME over ISO in many different ways. So, without benefit of double blind listening tests and IMHO, LAME is far better than Blade. LAME is ISO plus improvements so it has to be. Take a look at the LAME web page http://www.sulaco.org/mp3/ and click on the link "Quality is substantially better than ISO". I was hooked as soon as I read how they made all the improvements. mark stephens - Original Message - From: "Dimitris Tziouris" [EMAIL PROTECTED] To: "MP3 encoder list" [EMAIL PROTECTED] Sent: Wednesday, November 24, 1999 3:11 PM Subject: [MP3 ENCODER] BladeEnc vs. LAME at high bitrates Which encoder do you think has the best quality at bitrates over 160? With regards, Dimitris -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] BladeEnc vs. LAME at high bitrates
I don't think Blade has any quality improvements, just speed. If you read his history you will see he only worked on speed and left the quality alone. mark stephens - Original Message - From: "Shane Wegner" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 24, 1999 9:10 PM Subject: Re: [MP3 ENCODER] BladeEnc vs. LAME at high bitrates -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Typo
So minor, but The new -B feature text says miximum instead of maximum. Thanks for adding the feature Mark, and thanks for the reply concerning VBR improvement. mark stephens -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] get_audio.c and MSVC
Howdy,
Rank newbian here, so please excuse if this has already been brought up.
Getting the latest Beta source (3.36) and attempting to compile get_audio.c
gives me an error, 'constant expected'.
int fskip(FILE *sf,long num_bytes,int dummy)
{
char data[num_bytes] --
This doesn't fly in MSVC 5. It always wants a constant value when defining
arrays.
thanks for the great effort!
mark stephens
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] VBR routines
Howdy,
taking a look and adding debug output to VBR_iteration_loop in quantize.c, I
have a couple of questions. I probably don't have a complete understanding
of what I am looking at, but here goes anyway.
First, It appears that it starts at the max bitrate and work our ways down
to the min bitrate, calling outer_loop each time and comparing the noise
values to see what rate is the best. I put in some output to print the
variable 'better' for each loop and observed that, for most of the cases,
once better was 0 (false), it usually stayed false for the remaining
attempts. I put a break into the better test,
if (better)
{
save_bits[gr][ch] = this_bits;
this_bits -= dbits;
}
else
{
this_bits += dbits;
break;
}
to exit the loop. As I expected, I observed a slight speed increase, but
also a slight rasing of the average bitrate. In my test 167kbps became
172kbps. Comments?
Second, since it checks for noise values each time, in VBR_compare, is there
someway that VBR quality can be used to come up with an acceptable max noise
value and once achieved the checking quits. The loop can start at the min
bitrate, check noise, and if not ok proceed up to the max_bitrate. This way
the program always does at least one time consuming outer_loop, but only
does more work if quality is not acceptable. In other words, optimize by
trying to do as little work as possible.
I would also like to see a max_bitrate command line option for more complete
encoding control. For my ears, and the jazz I encode, 160kbps sounds real
perty. There are some passages, however, that obviously benifit from
192kbps, but I can't hear any difference at even higher bitrates. I grunged
the code in order to encode my music at 160 - 192 VBR, most songs averaging
176kbps. I kept the vbr quality at 5, not sure how this effects the
process. Locking the encoder down to 2 bitrates does speed the encoding
process, and if the above observations are correct, I can see how it could
be made even faster.
thanks.
d:-)
Mark Stephens ([EMAIL PROTECTED]) - Fairfield, OH Zone 5
http://home.one.net/users/markws - Our Backyard Forest
http://gilmore.pond.org - Gilmore Ponds Conservancy
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
