Re: [MP3 ENCODER] Interesting high quality settings and possible bug
Hello, Hrmm... that is an interesting idea. I completely hadn't thought of this. Does this actually take away bits from being used to encode the audio frame? If so then what is the real use of this switch? I had thought this switch would help to prevent the mp3 from being possibly corrupted by being transferred over and over again. Not that this really happens often but I thought why not. If however this switch really isn't that useful and it takes bits away from being used to encode the audio then I will stop using it. Currently I haven't noticed any degredation in sound just through normal listening tests, although I haven't looked into the matter further. I will do some testing and see if encoding without this switch seems to have any impact. -p is for adding a crc check to every frame. It does not prevents any corruption of the bitstream, it just help to detect if it has been corrupted. As it uses bits for the crc, it will lower (a little) the quality of CBR encoding, and will higher the filesize of vbr. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[6]: [MP3 ENCODER] -q1
also: isn't that "-35" not extremely harsh on the athlower? I think that using a negative value with athlower is a bad idea. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Winamp/100hz bug: SOLVED!
Should we change IXMAX_VAL to 8191? pros: 1. as Rob points out, less false syncwords in the bitstream. (8206 is encoded as 0x1FFF). 2. LAME produced mp3's will no longer trigger Winamp bug. cons: 1. Winamp may not bother to fix their decoder 2. Tiny loss in quality just to pander to Winamp users. (all Linux decoders I've tested do not have this problem) 3. LAME produced mp3's will no longer trigger Winamp bug (so it will look like it was a bug in LAME :-) I'd vote for limiting it to 8205. The quality loss would be very minimal. It won't solve winamp's problem, but it's easy to fix in the decoder, now that we know exactly what the problem is. The advantage is that 8205 is 0x1FFE, which is not a valid syncword for mpeg1-2. With this, audio resync on corrupted bitstreams would be easier for the decoder Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- 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] MMX question
Oh, oh no!
Do you want to start a contest of writing the dirties possible program?
main(_){float x,sin();for(_=0;__*_8;_+=_) ...
you forget the reverse access to arrays :-)
int a[5];3[a]=2;
--
Gabriel Bouvigne - France
[EMAIL PROTECTED]
mobile phone: [EMAIL PROTECTED]
icq: 12138873
MP3' Tech: www.mp3-tech.org
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MP3 encoding speed : LAME XING
The Xing MP3 encoder is exceptionally fast. Do they cut corners to get such high performance? Is their code written in assember? What (if any) chance of getting similar speed out of LAME? The Xing encoder is quite limited with regard to input sampling frequencies and output bitrates. Has anyone done testing on quality? The Xing encoder is not a reference in term of quality. It's right that it's fast, but now the new FhG engine is as fast as xing, but with a better quality. Yes, Xing cuts corners. An example is that it only uses long blocks, and thus doesn't compute short ones. Yes, it contains a lot of assembler and mmx code. And yes, there is a chance to get similar speed but with a lot higher quality with lame, one day. The priority with Lame is quality, so quality improvments are made first. Before optimizing to mmx a function, we must be sure that this function won't be upgraded soon, this is why there is only a few mmx on Lame. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] 3.87b MMX and no MMX give different results + some 3.87 comments
# of S frames/ total # of M/S frames]. Room enough on the lines :) 4) Why does the MMX mode and non-MMX mode give different output on my Cel450/Win95OSR2? Isn't MMX supposed to give same results? On my Linux Box with a Pentium 166 MMX the MMX and non-MMX version produce bit identical results. I compiled both releases (with and without mmx) with VC6, and the mp3 output is bit identical on my Cel460/win98. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MMX question
If the mmx version of choose table is used for the compilation, what will happen on a non-mmx cpu? it will crash, and it does so on my old P100. That's bad. Would it be possible to compile both routines in the same binaries, with an auto detection? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] intensity (was: Miscellaneous MP3 questions)
Yes, this is how the decoder figures out the break between M/S or L/R and intensity. But how does the encoder decide where to put the break? Clearly it is a tradeoff between quality and bit usage. A naive algorithm would exhaustively try all 13 or 21 possibilities for intensity start bands and choose the one which had the highest quality/lowest bit usage (reconciling the two is clearly a problem), but this seems prohibitively computationally intensive... I'm wondering if anyone knows of a less naive approach. Here is what I think: First of all, I would encode each time m/s instead of l/r, as (if I'm not wrong) the middle channel can be used for the intensity encoding by just dropping the side. Humans are less sensitives to the direction of the sound at both extremities of the audible freqs. So I'd start by encoding in i mode the first subband (like in triphonic systems), and after reducing to i mode starting from the latest band (22th) down to a given freq, according to the number of bits you need to save. According to the DTS whitepaper you can go down to 3-4kHz. But it's perhaps a little too simplist. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] off topic: AVI Encoder
I can do that already with CDEx but that integrates the LAME compression as well so I can go straight from a PCM Wav file to an MP3 Wav file. The only slight problem comes with larger AVIs where the file size of the AVI with uncompressed data goes over 2 Gb rendering the file non-standard and, therefore, useless. Well, if you want to stay under win95/98, you can use FlaskMpeg to backup your data, as it includes a built-in mpeg-2 decoder and got an avi output plugin. It helped me a lot, as I now don't have to decompress first in a big wav before re-encoding. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] AVI Encoder
I'm currently making quite a few AVIs and have had to use a kind of kludge to get LAME MP3s working for the audio segment of the AVIs - I have to use VirtualDub to extract the uncompressed sound track to a WAV file then CDEx's LAME plugin to compress that WAV file to a WAV file containing MP3 data. My question: is there a LAME CODEC which could encode audio into an AVI file directly? I think that you're not alone in this case. Let me guess: you're encoding large AVIs from a video source which is 720pixels wide, and your files are about 1H30 to 2H longs ;-) ? At first it would be nice to have a --l3wav option in lame allowing to output an mp3 with a wav header. About the ACM codec, there is none yet. It will perhaps be easier to write one when the ACM Vorbis codec will be finished, I only hope that vorbis guys are not waiting the same thing about lame. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] various questions (was: Some suggestions for LAME - please review)
MP3 uses 576 and 192. When 576 is too low for tonal music and 192 too long for percussions, then this is right. But a 1:8 ratio can create other problems. Note that MD uses 128, 256, 512 and 1024 sample blocks. Useful are block sizes from 1 ms ... 35 ms. Minidisc also uses mixed windows. Perhaps mixed windows would help in our case. I've got another question about window sizes: are the short ones really essential in VBR? Would it be possible to only use long ones, and then allocating a lot more bits in the case of transcients? After all, Xing uses only long ones, and does a not so bad job for transcients for an encoder using only long ones. (note: I'm not saying that Xing is a reference in term of quality) 5. Spectral prefiltering to get nearly constant ATH in every CB. Why can we read in the litterature that humans got 25 CB but mp3 uses only 22? I believe noise shaping is the main difference between different MP3 encoders. I'm sure MPEG did not document any good noise shaping algorithms on purpose :-) There are a few simple things in the literature, but I've never found any documentaion of a noise shaping algorithm used in an actual commercial encoder. Have you tried digging into audio patents? It would perhaps bring an idea. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] various questions (was: Some suggestions for LAME - please review)
Why can we read in the litterature that humans got 25 CB but mp3 uses only 22? let us try to get it in order: bark scale is used by the spreading function Bark 0 : 0-100 Hz, Bark 24: 15.5 - 20.4 kHz masking is calculated for convolution bands Lame uses 64 equidistant convolution bands from 0 Hz up to Nyquist each of the 22 scalefactor bands is responsible for a group of subbands (the convolution bands), but we have only 21 scalefactors (12 scalefactors w/ short blocks) So the highest subbands don't have any scalefactor? I know that Brandebourg said that there is no proof that 16kHz really contribute to the hearing of the music, and then it could be intentionnal, but could it be a "bug" or mistake in the mp3 specs? After all, I think that in 48kHz encoding some freq higher than 16kHz got a scalefactor, so it could be theorically be possible to affect a scalefactor. Is there a scalefactor for 16kHz in AAC? (Meno, are you listening?) Also an off topic question for Robert: as you're german, is there a specific knowledge about audio compression floating around in your university? (like specialists, research or thesis) Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Some suggestions for LAME - please review
how about altering some of the mp3 specs themselves and creating a lame specific mp3 variant? are there any legal reasons not to do this? would the quality gain be worth the effort? The problem is that no player would them be able to play the files. MP3 is an internationnal standard, and I think that we must follow it. For creating a new standard, there is another project called Vorbis. Regards, --Gabriel Bouvigne - France[EMAIL PROTECTED]mobile phone: [EMAIL PROTECTED]icq: 12138873MP3' Tech: www.mp3-tech.org
Re: [MP3 ENCODER] latest sfb question
:: Frank, that's not what Gaby is talking about. :: But if you are talking about the spreading function, there :: are more parameters than loudness: :: - frequency :: - tonality :: - temporal effects :: - difference tones reducing masking :: You've forgotten one: - frequency response of the audio equipment and listening room, especially interferences and hall. See remarks in AAC listening test. Yes, but it's not the encoder's problem. Moreover, this doesn't change anything to the current problem of sfb21 when lowering the ath. Am I the only one thinking that there is a problem? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] castings (OT)
It's taken from: Kerningham Richie: Programming in C It's not a compiler, but a book. The German translation is *different* from the original. Some additional remarks are taken from the ANSI Standard (1990). Highly respectable source, but parts of the KR syntax are now deprecated in Ansi C. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] mobile phone: [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] latest sfb question
The whole sfb21 thingy is a kludge, we should extend psymodel.c to calculate maskings for that band too. the ATH is so large in that band, I would be afraid that any computed maskings would always be ATH, and thus not worth computing? Wouldn't it be possible to use the ATH value as masking (as now), but use this value in the masking computing? It should prevent to lower a lot the overall masking for sfb21 when using something like --athlower 100. After all in the others sfb when using --athlower 100 the whole masking is not reduced, only the ATH. I'm afraid that now, using --athlower 100 would result in an incredible ammount of bits in the latest sfb. I'll test it and post the results. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] latest sfb question
Ok, but how about --athlower 100 ? Will it leads to an endless loop? That could be a problem. I think that when --athlower is used, the lowering of the ath in sfb 21 must be reduced for vbr. Did you notice any endless loop using --athlower ?? I tested the behaviour of lame vbr-old with --athlower 100. The good news is that there is no endless loop. The bad news is the result. I used lame -V1 -h -mj --athlower 100. With --lowpass 15000 the mp3 is 181.9kbps, wich is about what I expected, no problem here. But with -k the mp3 reach an average bitrate of 320kbps because each frame is 320kbps. What I suspected is happening here: an incredible amount of bits are used in sfb21. Why would any user would use such an high value of --athlower? (ok, 100 is a little too high) Because I think that the default ath for v1 is too high, and I don't want the low intensity passages to be cut-off. But I still want to benefit of the analog silence-32kbps for parts where the intensity is very low, ie no instrument playing, only the potential noise of the recording material, wich I know to be extremely low for some of my recordings. This is why I'd like to use something like --athlower 50. This is why I think that trying to put the sfb21's ath value in both masking and ath would be good, if possible. This way, using -v1 the sfb21 masking would still be reduced, but it would be possible to also use --athlower with some high values. Regards -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Psycho masking (once again)
Hi! Nobody interested in implementing some sort of psycho masking in lame... (see attachment Dolby, Fraunhofer) Regards Piotr Borowski Do you think that according to those graphs AC3 and FhG models are better that Lame? It allows us to see that at 256k the FhG acm codec does not provides full frequency response, but that's all. Moreover your sample is not good for testing a psy model. Psy model is made for modeling the human hearing, not an electronical analyser. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Lame resampling
The results of the modification of the resampling filter size are shown here: http://bboard.mp3.com/mp3/ubb/Forum1/HTML/003127.html Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] problem in layer2 decoding?
Here is the log: Microsoft(R) Windows 98 (C)Copyright Microsoft Corp 1981-1998. E:\templame -h -b112 test.mp2 test.mp3 LAME version 3.87 (alpha 16, Sep 16 09:04)(http://www.sulaco.org/mp3/) Using polyphase lowpass filter, transition band: 13692 Hz - 14226 Hz Encoding test.mp2 to test.mp3 Encoding as 44.1 kHz 112 kbps j-stereo MPEG-1 LayerIII (12.6x) qval=2 Frame | CPU time/estim | REAL time/estim | play/CPU |ETA 700/741(94%)|0:06/0:07|0:07/0:07| 2.7276x|0:00 Erro r: number of channels has changed in mp3 file - not supported. Error: samplerate has changed in mp3 file - not supported. 740/740 (100%)|0:07/0:07|0:07/0:07| 2.7272x|0:00 The first thing is the reported problem. Is anyone interested in the mp2 file? (it's 900k). The second thing is about the skipped frame. If the problem is in the mp2 decoding, I think that it would be better to repeat the latest valid frame than just skip the invalid one. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] mp3 wav header
I've got a question: is there any program allowing to add a wav header to an mp3 file? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] problem in layer2 decoding?
Gabriel, Post the file somewhere on mp3-tech.org or other ftp site , so we can take a look at the problem The file is on gabriel.mp3-tech.org -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Ogg Vorbis beta 2 still has a long way to go.
Yes, Roel was abit rash, but more than just a little justified imho. Don't deny that quite a few of you were overpraising Vorbis long before it actually was much to praise .. sure, it's a format with much potential, but it hasn't reached much of that potential yet, and stating that it's an "mp3-killer" already is way exagerated. I think that there are 2 things that need to be separate in our minds (at least it's my personnal opinion). To my mind the Vorbis format and the current Vorbis encoder core are 2 different things I think that there is on one side the vorbis specs, and on the other side the current vorbis encoding core. According to the specs (although it seems to me that there is a lack of documentation about it), vorbis has a lot more potential than mp3. But there could be a lot of different encoders using vorbis, with different strategies. Until now, we only have one, and this one is in beta stage. But the specifications are not in beta, they are finalized. But if you are a company working with music, developping a vorbis encoder is a not very good financial thing. It probably costs a lot less to pay the 15000$ each year to FhG or to wait for another company to developp a free vorbis encoder (in our case Icast) than paying some people to developp another good one. I think that vorbis is far from it's potential quality because there is only 1 full time developper and a lot of things to implement. Brandeburg wasn't the only full time man working in the natural audio division of FhG, Johnston wasn't the only full time man working in the natural audio division of ATT. Monty is the only full time developper of vorbis, and he's a simple human, unable to work 72h each day. That's why I think that vorbis encoder will take a lot of time before reaching the full potential of vorbis, or beeing close to it. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --voice
I've just been trying to help someone with re-encoding from 160/128 down to 96 kbps for his portable player so I offered -mj -b 96 --mp3input. This works fine but took longer than expected (perhaps because Lame seems to automatically resample down to 32 kHz ?), - are these the best options for optimal quality/filesize at 96 kbps ? I would add -h Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: --voice
I could not find the --voice page. is there a specific URL ?, - or which section is it in ? http://www.multimania.com/bouvigne/lame/voice.html -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[4]: [MP3 ENCODER] Ogg Vorbis beta 2 still has a long way to go.
M Anyway, he apologized, I apologize, we were on the bad crack today. We can M finish this up over some beer or good single malt. I feel this 'urge' to let everyone on this list know that I think beer is a poor man's drink. ;)) Be carefull Roel, free beer doesn't mean free speech... (I'm not serious of course) [curious thing is I never seem to offend any ladies on this list] A good point. Is there any lady on this list. I think that a lot of people subscribed to this list. Statistically, it would be strange that only men subscribed. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] min bitrate and bit reservoir (was: MS switching)
There are two possiblities for display update frequency: 1st) #define I_HAVE_NEVER_SEEN_LAME_ON_A_486_100_OR_A_ATHLON_1000 and display updates every 50 frames (MPEG-1) or 100 frames (MPEG-2) (Why this differences?) This difference is probably because in mpeg-1 there are 2 granules in a frame and in mpeg-2 there is only one. This also prevents lame from update frequencies in the range of 50...60 Hz (resulting in additional hum!) on Athlon 1000 systems coding mono, low quality MPEG-2 files. Sounds worse. Are you saying (I hope say is correct) that on fast systems, Lame display changes the result of the mp3? If this is the case, I think that we MUST find why. Otherwise note, that the old behave updates display every 4.5 minutes (386/40 with Cyrix copro, 8 years old) or 8.5 hours (386SX/16 without copro, 10 years old). off topic: is there anyone on this planet encoding mp3 with a 386? The slowest thing I personnaly used for mp3 encoding was dx4-100, and it was really awfull. 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 ;-) There are 2 indications of the remaining time in Lame: one for the remaining time for the Lame process, and the other for the overall system remaining time. Tthey could be different if you're using a lot of simultaneous tasks on your computer. But I don't remember which one is which one, and I'm not sure if it works on every OS. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Percentages (informational)
May be too difficult for end users, but nice for development. I don't think that it may be annoying for end users. Another question would be, what is best: * Showing the percentage relative to the number of already coded frames I would personnaly vote for this one. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --voice
Could someone satisfy my curiosity about this option (descibed as 'experimenatl' in the docs for ver 3.85, butI see that it is available in RazorLame) ? Does it have fixed default parameters like the --preset voice option, and if so what are they ? What is the thinking behinfd this option - audio books perhaps ? Many thanks Eric --voice was made before presets. Now that we have presets and filters in Lame, --preset voice is the same as --voice, and --voice is usable for any sampling rates. I personnaly think that now --voice should be removed in the benefit of --preset voice, but some people disagree about it. If you're really interested about what was behind this option when it wascreated, I still have a webpage about it. Regards, -- Gabriel Bouvigne - France[EMAIL PROTECTED]icq: 12138873 MP3' Tech: www.mp3-tech.org
Re:[MP3 ENCODER] min bitrate and bit reservoir (was: MS switching)
The 4 examples I brought were POSSIBLE information you have after coding a PCM file. These are possible scenarios after you have coding files. You've tried to do your very best and you see after coding it wasn't. Real world examples and exercises: After coding with -V0 you got: --snip-- Calculate the file increase for the options '-b160', '-b192' and '-b192 -F'. Is this tolerable? What to you expect about coding quality? --snip-- Calculate the file increase for the options '-b112', '-b128' and '-b128 -F'. Is this tolerable? What to you expect about coding quality? In both cases I think ( I didn't really calculate) the size increase should be something aroud 5%. Yes, it's tolerable, but I personnaly don't think that this would increase the overall quality by 5%, So I personnaly don't use any minimum bitrate (but for classical music I use --noath). But I don't get your point about what you're trying to explain with those examples. FhG forces 48 kHz on 320 kbps. Maybe to bring the bits/granule ratio to the right place. But in VBR mixed sampling rates are fordidden. Also I extended the brhist function to display percentages between 0.05 and 1 more accurate. a good thing. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] MS switching
FK -V0 * file size is increased by 1.2% by setting -b128, so use this option FK * only two frames are 320 kbps, so also use -B256 to avoid problems FK with some players I am fundamentally agains crippling an encoder to fit the needs of an inept decoder. If 320 is chosen by LAME on -V1, it is there for a reason! This point is debatable. I am in the clan of the people using -B 256, and here is why: I choosed to keep strict ISO compatibility (--strictly-enforce-iso), because if in the future I use an hardware player, I would be worried to have some of my mp3 becoming unplayable. The ISO standard specifies a strict limit for the data size (btw this limit was choosed too low in the standard) so 320k frames can't use the bit reservoir, and if there were some available bits in the reservoir, if a 320k frame is used, the reservoir is definitely wasted. As I don't want to have too much unused space in my files, I choosed to use -B 256, even if I might be sacrifying a little of quality. In the past, when Lame was using strict iso, because of this reason the default for -V1 was -B 256. The Xing vbr encoder also limit up to 256k frames in order to not waste bits. (I don't know about the FhG vbr). Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[4]: [MP3 ENCODER] MS switching
GB This point is debatable. GB I am in the clan of the people using -B 256, and here is why: I choosed to GB keep strict ISO compatibility I didn't know ISO only allowed up to 256. Then I understand you. It's too late anyway for my huge amount of vbr albums, so I guess I'll have to buy myself a player anyway that supports up to 320. I didn't said that ISO only allows up to 256k. You changed the meaning of what I said by cutting text of my post (unintentionnally I think) . What I said is that ISO does not allows 320k frames to use bit reservoir, this thing leads to wasted bits when there is a 320k frame, and that's why I choose to limit to 256k. This rectification seems important to my mind. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] very lowand very high-quality settings
for some reason I have to convert something like 200 CDs to mp3 and they should stay on 4CDs. An average bitrate of around 32kbps should be o.k.. What lame-options do you recommend? I did some very unprofessional testing and came to this: -V4 -mm -h -b24 -q1 --resample 22.05 I would choose something like lame --abr 32 -h -mm --noshort input.wav output.mp3 Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Layer II (was: mpglib compiles once again...)
I just want to ask which layer2 encoder do you prefer or recommend?? (SOLOH or toolame?) I'd recommend using Qdesign. If you want a free one, I'd use toolame rather than Soloh, as toolame is soloh+some improvements. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] problems with LAME CVS
// pfk // For 44.1 kHz // 1... 96 kbps: Mono better than ugly stereo °) -- // 97...159 kbps: Joint Stereo -- // 160...192 kbps: Force Joint Stereo bandwidth not enough for LR stereo, but reducing switching artefacts // 193...kbps: Stereo enough bandwidth for LR stereo // // °) mostly prevent by automatic downsampling Why using forced joint by default? I'm personnaly againt it, as it leads to spacialization artifacts. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] cwlimit (was: very lowand very high-quality settings)
lame -m m -h -b32 --voice --lowpass 8 --lowpass-width 1 --highpass 0.054 --highpass-width 0.04 --cwlimit 7 --resample 22.05 --noshort a.wav a.mp3 NOTES: cwlimit=lowpass minus lowpass-width (kHz) Did you played a lot with cwlimit? Could you please share your results about it? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi Pass MP3 Encoder
What about the idea to allow the user to code the file in two passes for the very best quality by the extense of doubling the CPU time. Some video encoders (ex: mpeg-2 media cleaner encoder) are using 2 pass encoding, and it seems to substancially improve the output MS/LR switching can be optimized in a seconds pass. Also the bit reservoir can be better balanced. About the bit reservoir, I understand, but for the m/s switching, I don't understand how multi-pass would help. Another thing is that multipass would allow VBR with a predictible file size. But I also suspect that multipass would need a lot of coding. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] low frequencies (was: Correlation mid/side)
You should apply a 16 Hz lowpass filter for DC removal. Note that lowest organ note has 16.3Hz. Iso recommends an high pass filter of about 10 Hz. But there is something I don't understand about it: the first subband is a lot wider than something like 10 Hz, so how can such an high pass filter be usefull for mp3? I think I must be missing something about it. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] newbie question
On www.r3mix.net, the following command line is recommended as the best option (size, speed, quality-wise): -V1 -h -mj -b128 -q1 I was looking over the documentation that came with the zip file of LAME 3.86b, and I couldn't find any mention of the "- q" command. I didn't documented tha -q switch because it's a beta switch, and its behaviour can change from a release to another. The final goal of this switch will be to create a quality setting, going from -q9 (worst) to -q0 (best), but it's not finished yet. Can someone here explain? Does it apply only for VBR, or can it be used with CBR as well? It can be used with CBR as well Thanks. One last question, for the best quality at the expense of file size, is "-b 320 -h -k -m s" the best option? This is likely to be the best quality setting, also some people (like me) could argue that -m j would be able to give better quality. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the -mx mode - different philosophy
-md is not documented. What is it ? Does anyone made a dual channel mode? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[4]: [MP3 ENCODER] RazorLame 1.1.0 released
perhaps it is time for someone who fully understands all the options/switches to settle down and write a comprehensive 'Help' file for Lame, - I doubt many who use Lame with a front-end or ripping utility bother to read the 'Usage' file that accompanies the exe file and I don't think users of the dll file even see it. I'm trying to do it in the html doc. I plan to add to it a page about the basic options because there are now too much ones in the full switches page. If you've got any suggestion about the html doc, please share them. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Some of the test signals
I've improved the correlation calculator a little bit, so not only the correlation of the pure signal is calculated, but also the correlation of the (in time) differentiated signal. Normally the correlation of differentiated signal is a little bit lower than the of the original signal. But a lot of the test signals on the Web-Server are really strange (The first line is the origin, the second the diff'). Correlations differs AC x AC y r 32.637% 33.327% 88.061% technik/Castanets.wav 23.530% 23.429% 65.664% technik/Castanets.wav Am I the only one wich doesn't understand what Frank is telling? Can anyone explain a little? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the -mx mode - different philosophy
First, please note that it has been a long time I didn't really looked inside of the Lame code, so I'll perhaps tell a few wrong statements. (btw, please could anyone explain me when to use the word "tell" and when "say"?) If I understand correctly, the "-mj" is evaluating if a frame qualifies for M/S coding beforehand, and if so, it will then be coded in M/S, independent of the outcome. There is also another parameter: trying to minimise the toggling between s and ms I've heard my fair share of examples where lame opts for M/S, but afterwards this is a bad choice, giving a M/S frame sounding much worse than S would have, or in vbr, more bytes are used on the M/S frame compared to the S frame. Does this really happens in vbr? Could you please try using Mp3x and see if the same frame could sometimes use more space in ms than in s? It seems so strange...If it's true, I think that there is a mistake somewhere in the ms bit allocation problem: once the criterium is met, and a frame tagged as "M/S"-material, it will always be a M/S, even if S would have been better. Not always: I think that if we got something like s-s-s-ms-s-s it will be converted before bitstream formatting to s-s-s-s-s-s in order to reduce the togling artefact. Big advantage of this prediction method is the speed. I don't know if it's still the case, but in the past both ms and s data were computed as the mode of a frame could be changed according to the next one. Since you never have 100% accurate prediction this is one of the most prominent causes of poor quality in -mj mode. (read that post of me referring to 192JS of the Velvet track) This Velvet track must have some (perhaps not yet known) other difficulties, as the results are quite catastrophic for every encoder, including mp2 ones. What I'm suggesting: a "-mx" mode (or whatever letter) it would be a JS mode, but unlike the "-mj" mode it would not try to predict anything, but just achieve optimal quality in an empirical way. This is, to my mind, the goal of -mj, so any change should be made into -mj I'd be slow, but it'd be the best possible quality for cbr and best quality/size for vbr. (as far as I can see) not so slower, if both sets of data are already computed just my 2 centimes about it... Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] the -mx mode - different philosophy
I'm not equiped for listening tests here (only an awe64), but is the velvet problem the thing I'm hearing in the right channel? (or am I thinking I'm hearing something?) If this is the case, it seems to me that it's reduced in -m f, but the stereo image is also changed by this switch. If it's gone in forced mode, it could be a toggling problem. Roel, could you check this? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] attitude
Frank: if your point is that a compliant bitstream is generally not the best sounding one (where 'best' is defined by your taste), your point is now well taken, and we can all read up on more effective interpolation schemes to our hearts' content. If, however, your point is that Rob was wasting his time by doing the compliance testing, your point is not well taken; many people on this list actually appreciate and encourage this sort of selfless activity. ISO 11172-4 may seem or even actually be stupid (it is from ISO, after all), but it's what we have to work with, for better or worse. I don't think that Frank was trying to reduce the value of Rob's test. He just explained why this ISO compliance is not completely defining a standard of quality. Please let's try to stay gentle on this list, we're not on a vqf.com or dmusic.com message board! Another point about it is that in english, it seems that a lot of things like "in my mind", "in my opinion",... must be used in order to not beeing perceived as beeing rude, but it's less evident in other languages and not necessary a reflex for non-english people writing in english. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] win32
Why do the win32 versions not show on the fly bitrate analysis for vbr files? They do. Try the one located on mp3-tech.org, and you'll see bitrate analysis Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] html doc
here is the 3.86 doc Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org html.zip
Re: [MP3 ENCODER] Free format
I'd like to find a free format encoded file. Does anyone of you know where I could find one or an encoder that support free format (also known as free bitrate) ? lame --freeformat -b yourbitrate in.wav out.mp3 Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] MPEG audio decoder compliance
RL If you can point me to a specific implementation I can try to test it RL directly. The only requirement I have is that the implementation support some RL way of saving the decoded output to a file (e.g. WAV). Would be great: http://www.daansystems.com/coolplayer It's useless as this player uses Xaudio Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Voice encoding questions
F We should support an option (-ma for Mode Auto) which switches F between -a -mm for highly correlated channels (r 0.98 = F mono), -mj for a normal correlated signals (r = -1.00...-0.20, F 0.20...0.91 = stereo) and -ms for nearly not I am afraid most of decoders can't treat an mp3 file correctly whose mode(stereo - mono) is changing during one file. Switching between any stereo modes (stereo, m/s, is, ms and is) is allowed, but switching between stereo, mono and dual is forbidden by the standard. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] 3.86a, bug with -h ? [re-send]
What about an option "adjust-level-for-psycho-model", which increases the level for the threshold computation, so low level music is coded with more bits. To my mind low level pieces of music with a turned up volume control are coded with too less bits. lame is coding for a full scale SPL of about 90 dB and that's too less if you are listening at 100 dB full scale SPL. Options like '-b128' don't solve this problem. For medium level music there are still too less bits. Only the low level parts get enough bits, may be also too less. This seems to be an ATH problem. But isn't the ATH adjusted according to the VBR scale? It's right that a switch to manually adjust the ATH would be good, as I also think that some low level pieces of classic music are encoded with too few bits. A rough solution is to completely disable use of the ATH with --noath Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] VBR modes question
I've got a question about VBR (the full scale one) Will the mt code completely replace the rh code (in several releases)? Or do you think they will continue to coexist? Do you think that they sould be both documented in the doc? Mark, Robert, anyone else, any opinion about this? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] DC cancelation
2nd problem ~~~ Some of my CDs have a lot of DC offset. Other are well DC free. Examples: What is DC? -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: 3.86a, bug with -h ?
For my ears, Takehiro's scalefac_scale feature will not give better results. The quality of many tracks is a little bit lower. I have found no tracks with better quality. The file size is reduced, but for my opinion, the quality is more important. So i think, setting this feature as default is not a good idea. I'm using an electrostatic headphone, Stax SR-40. It is a little bit old, but its quality is very high. Jack So it also means that with this feature and the same filesize, the quality could be improved each time. This is why I think that when scalefac_scale is used in vbr, it would be good to change a little the vbr scale, or coefficients affecting the file size. Is anyone ok with this or am I saying (telling? I never know wich one to use) something wrong? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Voice encoding with low bit rates
I have briefly tried the "--voice" mode and the "normal" mode when encoding a purely voice signal (with background noise) at 8kbps, and have been very impressed with the difference. I would like to compress the signal more... but 8 is as low as it goes. The "nomal" mode renders the voice absolutely unintelligible (I assume the encoder tries too hard to preserve the background). The "--voice" mode actually seems to reduce the background garbage (noise) where there is no speech, and to also concentrate on the speech when it is present. I have looked at the spectrogram for each, and there is a BIG difference. My question (after all this guff) is "does LAME perform any smarts (like looking for particular frequency domain patterns), and if so, what?" I have read most of the past articles on "--voice" but they don't tell me all I wish to know. I am also starting with a 11K/samples per sec file (mono) and having to up-sample it to 44.1K before I can process it. Has anyone considered allowing different input sample rates (ie: the standard 16, 22.05, 24, 32, 48) as well as 44.1 ? I first wrote the voice mode, mainly by using some supposition about the signal and a lot of listening tests. You can read what was done at the beginning by this option here: http://www.multimania.com/bouvigne/lame/voice.html Because of a lack of time, and the lack of good filtereing solution at this time in Lame, I only tuned it for 44.1kHz files. But now, Robert introduced the presets in Lame, including --preset voice, and Lame got some good filters. So I think that "--preset voice" is now doing the same thing as --voice, and can be used for any sampling rate, but I'd like Robert confirmation to know if the behaviour is the same as --voice. If it's doing the same, I'd suggest you to stop using --voice and start using --preset voice instead. I personnaly think that now the --voice switch should be removed, as there is --preset voice. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Voice encoding questions
- Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, August 04, 2000 4:14 PM Subject: [MP3 ENCODER] Voice encoding questions Howdy All, In testing my (comparatively naive) hack of the dist10 encoder, I have discovered that, while it does OK for music, it has real problems with speech signals. (Caveat: at our lowest overall bitrate of 300kbps for combined video/audio, we run the audio at 32kbit mono - though we go way up to 64kbps mono for higher overall bitrate signals, and are aiming to default at 64kbps stereo [not joint].) In particular, the broadband noise bursts associated with fricatives really wreak havoc. My test signal here is spfe49_1 from the AAC SQAM test suite, which is a female English speaker going on about giving pills to animals. I ran it through 1) my encoder, 2) LAME (3.85 w/ frame analyzer), 3) mp3enc31, and 4) our current Layer-II encoder. 1) With my encoder (64kbps stereo CRC), every fricative is almost painful to listen to, as the pink noise bursts end up being narrow band filtered (due to lack of bits - only the MDCT coeffs closest to the pole are making it into the bitstream), and there are occasional weird high frequency blips and arpeggiation which are very annoying. 2) LAME (-m s -h -b 64 -p --resample 44.1) (we use CRC and I haven't enabled LSF yet) sounds pretty good. There are occasional minor glitches, but that's to be expected at this bitrate. However, LAME (as above plus -k to turn off the filters) sounds pretty similar to what I'm getting. I note that without the forced resampling, LAME will attempt to downsample to 22050. If you want to encode voice signals, I'd suggest you to use --voice or --preset voice 3) FhG (-br 64000 -qual 9 -crc -no-is -esr 44100) sounds very good. (Man, is it slow, though.) Again, without the forced MPEG-1 sampling rate, the mp3enc31 will attempt to use 22050. You're disabling intensity stereo, but not joint stereo. With those settings, mp3enc is using m/s stereo. This is an advantage over Lame that you forced to use plain stereo. 4) Layer-II (64 kbps stereo CRC) sounds good. The layer II encoder is probably using joint stereo. In Layer II, joint stereo is quite similar to the intensity stereo of layer III And what is the capital of Assyria? The first assyrian capital was Assur, and it was later replaced by Kalah. -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Voice encoding questions
So my question(s) are: Is the solution to my problem to filter/downsample (and use joint, when I get around to coding it up)? That seems to be what is making the difference in the case of LAME; I assume that FhG is using some filtering as well, though there's no way to disable it and see for sure. Are there really just not enough bits for this type of signal at this bitrate? Why does Layer-II do so much better a job with this type of signal? Do other codecs (AAC/MPEG-4) hand this kind of signal better as well? I forget something: the sample you're using is very closed to mono, so joint stereo helps a lot. For your problem, there are mainly 2 soulutions: a: downsampling b: using joint stereo. For voice signal, the best joint mode would probably be intensity stereo. But it's not implemented in Lame. You mentionned that you use crc. Are you aware that the ISO crc code is brocken? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Voice encoding questions
I like to think that I have fixed at least a few. Now that I've finished a first pass clean, rewrite, overhaul, and verify, I'm taking a closer look at algorithmic (as opposed to purely implementational) problems, starting with the main loop, and probably ending with the #^@% psych model. Of course, if advanced features are going to make a bigger difference, though, they may gain a higher priority. I'd suggest you to look at the archives of this list, and to look at Lame 3.00. It's code was probably a lot easier, and it was mainly bugfixed ISO with addition of joint stereo. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame Windows Binaries
A noticed a number of different binaries for Windows for version 3.85 of Lame. The ones from Russia are different then the ones from the MP3 org web site. The trouble is when I use both at the same settings and then compare the output, it is different. Would someone please recommend 'the' place for the latest Lame binaries for Windows? Size of binaries will always be different because I don't use any compression. The place for the latest binaries is Dmitry's website, with up to date binaries for alpha releases (from cvs). On mp3-tech.org, I only use beta and stable releases, but I don't want to use alphas, because to my mind they are not targeted toward final users but only testers ans developpers. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] -h (High quality causing ringing artifacts ?) ?
Taken straight from the cdex 1.30 beta1 help page, is this true with 3.85 ? does it really cause ringing artifacts with high quality on ? It has been right with a few betas in the past, but I think that now you can use the -h switch safely. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --nores
I ran a quick check: lame -b 320: average bits/frame: 8046 lame --nores -b 320: average bits/frame: 7917 So even at 320kbs, --nores should only be used for specialized purposes. I've personnally got a different opinion than Mark about it. The iso specs forbid usage of reservoir with 320k frames and up. So I personnally think that --nores must be used when encoding with -b 320. Otherwise, it could cause problems in players, especially hardware players. To my mind, --nores should be the default with -b 320, but different people got different opinions about it. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] new VBR code
I forget why the -B option was added, but it should not be used under normal circumstances. It was added because there are some decoder chips wich can't handle more than 192k frames. For (strange) cases like -b128 -B 128, why not made lame using cbr instead of vbr? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] LAME ID3 version 2 support proposal
So ... comments? Does anyone not want this feature? How about a different behavior? Or should I just start typing away now? :-) I personnally don't use the lame id3 options. But, personnally, I'd like to have by default both v1 and v2 tags if v2 are necessarry (ie more than 30 char), as many applications are unable to deal with v2 tags. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] ACM (2)
Note: Othe solution for the ACM bitrates is a "setup" program for the ACM codec and store the desired bitrates in the windows registry. To my mind, this would be a lot better, allowing users to choose encoding options (at least the major ones). This has already be done in the radium hacked FhG codec, in order to choose the stereo mode. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] new VBR
Now that -Y has become default, to produce average bitrates of around 128 (joint-stereo), I have to select -V9. This compares to -V4 with the old VBR. Does it need some tuning? I didn't tested it, but if -V9 is producing around 128k, I think the scale needs to be changed. And if it's producing 128k, how do we produce lower bitrates vbr? With using -V 15? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] About Vorbis
I thought the ISO source code was freely available from Fraunhofer's ftp site well before SoloH released his encoder, but then it was a few years ago now and time maybe playing tricks. Yes, the ISO code was freely available before SoloH used it. It's just another mistake like "Lame didn't succeded in obtaining an FhG license", or something like this. It seems that as long as an article is not written by some of us, there always be some mistakes in it. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Encoders genealogy
Xing evolved from tompg, which I think is also a direct descendent of the ISO code. The tompg source code is out there, so you could check. It's the second time that someone mentions the tompg sources as beeing available. But does anyone knows where to find them? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Re: legality (was: C++ LAME?)
David Balazic wrote: Yeah , but what if someone in Germany wants to use it ? He can not , unless he breaks the law. Isn't that the same with LAME and even an MP3 decoder? All you people using LAME in the US and Germany are currently breaking the law :-). Erik If you only release/download source code, there is no problem. Any user as the right to compile source code for his own use, as long as he doesn't release any binaries. So in the case of Lame, the Lame website, Mark, and all the people who download source code and compile themselves are legally ok. Those infringing the law are Dmitry, myself, and all the people downloading the binaries from our websites. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] efficiently do multiple bitrates at once?
The thing is - unless the different bitrates have the same frequency and number of channels then surely they are too dissimilar after the resampling to gain very much? Well, the psycho acoustics should be the same :-) Some things might be similar, like m/s choice, block type decision, but the bit allocation is diffinitively different, as the number of bits available is different and frequency distribution is different due to filters. So yes, you'll probably gain something like 5-10%, but I personnaly think that it's not enough to justify an heavy code modification. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] efficiently do multiple bitrates at once?
Some things might be similar, like m/s choice, block type decision, but the bit allocation is diffinitively different, as the number of bits available This stuff is not psycho acoustics itself. psycho is: window, fft, cb's, energy tonality computation, spreading function, threshold computation. After that you use it: fold to sfb's, m/s choice, ... is different and frequency distribution is different due to filters. You first filter and _then_ do the psycho acoustics? That's broken, IMHO. The filtering is done before. In psychoacoustic, (and also in psychovision) what is more annoying is not artifacts themselves, but changes in artefacts. High frequency limit change IS an annoying artefact. If the filtering was done after psycho acoustic, it would mean that the high freq limit could change from a granule to another, leading to a kind of high freq fluttering. So I'm quite sure you wouldn't gain 50% in re-using computations. This is my opinion, perhaps others could tell us what they think about it. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Portable MP3 Players
Mambo X http://www.mambox.com According to the sheet, it seems interesting. However it seems that there are only a few ones manufactured, and you could wait 3 months or more before getting your. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] efficiently do multiple bitrates at once?
Are the frequent cut-offs different at the higher bitrates, like 96, 128 and 192? (Yes admittedly I probably won't be streaming over 128kbit/sec, but I'm curious.) Yes they are. It would be silly to try encoding full frequency range at 96. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] today's idea
If we don't use reservoir much optimally, it may not be difficult. Here is a quick hack of such adjustment. Some parameters in this code are not the best value. I see some 0.6 in your code. I only used it as an example and I've no real idea of what the value should be, but I'll have a look... -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] today's idea
Here is today's idea for cbr encoding: assuming we have to granules A and B, A got a distortion level of 0.1 (arbitrary choosen unit) and B a distortion level of 0.6. The idea would be in this case, as B got an high distortion, to requantize granule A in order to get, as an example, a distortion ratio of 0.3. This would save bits, and increase the bit reservoir for next granule, which then could have a distortion ratio of 0.4. So the idea would be in the case of a granule containing high or very high distortion to reduce the previous granule quality in order to get a more constant distortion ratio. However such a thing would increase buffering complexity. What do you think about it? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame binaries
Probably because of different compilers, and different optimizations Regards, -- Gabriel Bouvigne - France[EMAIL PROTECTED]icq: 12138873 MP3' Tech: www.mp3-tech.org - Original Message - From: Ampex To: [EMAIL PROTECTED] Sent: Saturday, June 10, 2000 11:42 PM Subject: [MP3 ENCODER] lame binaries Why are the lame windows binaries on chat.ru, and mp3-tech.org not the same file size?
Re: [MP3 ENCODER] More on free formats
I suspected that "free format" meant that the encoder wasn't restricted to the standard bitrate options, so if I'm right about that if an MPEG Layer3 stream was freeformat had no bit reservoir, would it be natively VBR? In free format mode, each frame is required to have the same size Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Re: Vorbis (was Encode now or later?)
b: if using the pre-computed tree, the same codebook is always used? I'm not sure what you mean... The pre-computed tree is just an optimization to shorten search time on a given codebook. Each codebook has a custom tree generated for it. I was thinking that you were using a different codebook for each track, wich was transmitted with the compressed file. Are you telling me that you've got a set of pre-build codebook, and only those? Am I wrong telling that a specific custom codebook provides a more accurate result than a generic pre-built one? Perhaps that writing a quick description of the encoding process in the vorbis doc would save you time, removing a lot of questions like mine? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Windows front-end for Lame.exe: first beta of RazorLame available
BTW: would it be okay to "quote" from the HTML manual and the usage file? I think that they are implicitely both covered by the LGPL license, as they are part of the Lame package. Except this legal part, I don't have any objection for re-using the html doc, and I think that Mark doesn't have any against the use of the usage file. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mp3enc 3.1 and -l3wav (putting an mp3 inside a wav)
I doubt you want to hear this, but this should be a pretty easy program to write yourself. The hardest part would probably be finding a copy of the RIFF WAV spec (a Microsoft/IBM standard which is, of course, available at neither of their web sites), and then finding the details of specifying an MP3 encoded chunk, which is a relatively recent addition to the spec. After that, it's pretty much just a matter of generating a few 'chunks' of header info and patching them onto the MP3 data. If you're interested, but can't find the spec out there, email me, and I'll see if I can dig up my copy. Details can be found here : www.wotsit.org Perhaps a -l3wav option could be added to Lame? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Update
new message board: as the old one crashed, loosing about 1 year of valuable posts, I set up a new one. This one is more powerfull than before, allowing to search or to further edit posts. MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Update
Sorry, I posted to the wrong mailing list -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CSV source code
- Original Message - From: Distelrath, Anselm [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 02, 2000 1:08 PM Subject: AW: [MP3 ENCODER] CSV source code Do you use winzip? Is the Archiv a tar-archiv? Perhaps, you should experiment with the option tar- lf cr/lf conversion. Or use tar! Anselm Winzip handles well the cr/lf conversion. If you're using the tarball, there is something else to do, as the files contain all the modification steps, but I don't know what. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MPEG plus
- Original Message - From: Andree Buschmann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 02, 2000 5:26 PM Subject: Re: [MP3 ENCODER] MPEG plus it's based on the strucure of mpeg1-layer2 and therefore is a subbandcoder. there were some enhancements in lossless coding (intense use of huffman-tables for quantized samples, more efficient coding of scalefactors), some enhancements in the psychoacoustic model (like 'clear voice detection' which prevents voiced speech from becoming distorted or nonlinear spreading function) and some things that were not supported by layer2 (mid/side-encoding, adaptive noise shaping in subbands). the codec is recommended to be used in vbr-mode (quite low average bitrate) and seems to offer more 'stable' quality in comparison to other codecs. as i've been told with special hard-to-encode signals (like 'fatboy slim - kalifornia') it performs better at vbr with avg of about 140 kbit/s than mp3-encoders with 192 kbit/s... If I understood well, this was a student project, and thus you don't plan to make money with it. So you could perhaps share your work with us. ( ie explanations, source code, or contributions to Lame/Vorbis?) I'd like to know how you achieve such a difference in final bitrate compared to mp3. Lame also uses huffman tables and M/S stereo. So the only thing left is the psychoacoustic model. Woud it be possible to have further explanations? Note: I didn't tested MP+ yet, but explanations would interest me more than just using it. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] l3psycho_anal
In the big (too big?) l3psycho_anal function, in the "determin final block type" section, is there a way to know if the frame is m/s or stereo? I mean, is there something like blocktype[chn] to know it? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] The coder
Moreover, using a 15.1 kHz lowpass freq with 32kHz resampling is impossible. Oh, lame says it's filtering like this: "transition band: 15097 Hz - 15484 Hz", which I thought would be alright because 16kHz would be the cutoff frequency at 32kHz sample rate. Have I got this wrong? Yes, maybe -k would be a better idea all round anyway. Sounds fine on my sources. Please apologize, you wrote 15.1, but my (tired?) brain interpreted as 16.1. So you can continue to use your lowpass setting. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] decoders (was: Lameusagethingy)
With 320 kbits free format streams l3dec is at its limits: # Now decoding layer III, 44.1 kHz, free ca. 320 kbit/s, stereo # frame no: 130 # # ERROR (300c): Granule exceeds maximum dynamic part length I get this message trying to play back 320kbs CBR streams too, with or without "--strictly-enforce-ISO". So I think it just chokes at 320kbs in general. It had no problem handling 310kbs free format. Could it be because the iso doc does not allows usage of main_data_begin in 320k frames? Perhaps this should be inforced when setting the --stricly-enforce-iso switch? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Windoze batch/GUI interface?
Hello everyone! What batch/GUI front-end does everyone use for lame under Windoze? I personnally use Audiograbber with the command-line release of Lame. I use Audiograbber because I'm used to, but it's a commercial software. Otherwise, you could use Cdex Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] The coder
lame -d -h -X 6 -Y -Z --cwlimit 12 --lowpass 15.1 --resample 32 -b 128 ... This gives *very* acceptable results in the studio on all the test cases I last tried two months ago, including a very difficult track of choral music. I just have 2 observations: *to my mind, you should remove -d. This switch allows to have different blocks on the left and on the right, but as it's implemented right now, it requires a little more bits than without. So for vbr encoding, it's not a problem, but in your case, I think that it could reduce the quality (ok, just a little, something like 1%, but each percent of quality is important) * as you're using the --resample switch, I think that it would be better to remove the --lowpass switch. It's better, to my mind, to let Lame choose the lowpass freq, and thus avoid any possible resampling noise that may be introduced. Moreover, using a 15.1 kHz lowpass freq with 32kHz resampling is impossible. So in this case I think that it produces the same results as -k (full freq bandwidth). But once again, I personnally would avoid it. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lameusagethingy
Btw, what is Mad? Robert Mad is a young integer only decoder, quite fast. I don't remember the url, but there is some source code on my page. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] Normalize audio input
This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN ratio over the range of quant values. It would be easier to try answering your question after looking at this doc, but it seems that I don't have it. Is it possible for you to send it to me? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lameusagethingy
Hello , latest usage says: " --freeformat LAME will produce a fixed bitrate, free format bitstream. User must specify the desired bitrate in kbs, which can be any integer between 8 and 320. Not supported by many decoders. " Shouldn't this be between 8 and 440? Why 440 or 320? According to the ISO doc, it does not seems that there is any upper limit to the bitrate. (The only limit is perhaps that it seems that only Xing based decoders and a few mpg123 based are able to decode it) Btw, did anyone tryed freeformat on Xaudio or Mad? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] Normalize audio input
- Original Message - From: Roel VdB [EMAIL PROTECTED] To: Gabriel Bouvigne [EMAIL PROTECTED] Sent: Sunday, May 28, 2000 4:06 AM Subject: Re[2]: [MP3 ENCODER] Normalize audio input Hello Gabriel, Saturday, May 27, 2000, 2:44:36 PM, you wrote: GB Good point here. If I'm not too wrong, a kind of normalization can be done GB by just changing the scalefactor value. In this case, such an option would not change the GB encoding process. Lame could encode each frame as usual, but could change GB this value during the frame packaging. I think this should not interfere GB much with the main goal of Lame, wich is mp3 encoding. This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN ratio over the range of quant values. I don't understand why you would raise a input level by 3/4th, encode and raise to 4/3th whilst decoding, but I take there was a reason for this, and maybe this is not something to tinker with? I don't really understand the real utility of this 3/4 power. If someone knows about it, please drop us a line. About this normalization thing, here is a quote from Mark some times ago: "One easy thing would be to change the value of global_gain. it's an 8bit int stored for each channel of each granule. Changing this +/-1 changes the volume by .75db." It's the thing that I think could be used, without affecting the encoding process. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Bug with -q1 (win32)
I do not think that this has much effect on the quality, however, if you want to use the "-X" switch (also undocumented, although it should be), I always thinked that -XYZ were some experimental settings, and that theyr behaviour can change from one release to another. Is -X a "fix" thing?, and do you think that it should be in the html doc? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Audio format
Jose Mejuto wrote: Hello, Does anybody know what is the audio format of the EXE (Windows) files that are located in this server ? http://www.globalmusic.com/cybermp4/ They say that it is MP4, but what is MP4 ? AAC ? They call it mp4, but it has nothing to do with mpeg-4. They just call it mp4 to benefit from the confusion of the names. The format used is a modified AAC (probably low profile, but not sure about this). Regards, -- Gabriel Bouvigne - France www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Interesting thing?
Could someone please check this: http://www.stud.uni-hannover.de/~andbusch/audiocoder.html I don't know if it's interesting, as I don't understand the slightest word of german. Regards, -- Gabriel Bouvigne - France www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] bringing down one (more) mp3 restriction [LAME case projection]
vdbj wrote: (removed long mail) Perhaps we could add an advanced option for adjusting the encoder delay?. I know that if reduced to the max, it will lower the quality of the first frame, but in some cases it could be a better choice. Regards, -- Gabriel Bouvigne - France www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] bringing down one (more) mp3 restriction [LAME case projection]
vdbj wrote: Hello Gabriel, Thursday, May 18, 2000, 12:38:53 PM, you wrote: GB Perhaps we could add an advanced option for adjusting the encoder delay?. GB I know that if reduced to the max, it will lower the quality of the GB first frame, but in some cases it could be a better choice. Wouldn't that be trying to repudiate the inherent nature of mp3? Isn't it quite impossible with those MDCT thingies to represent impulses? It might work, but at a quality cost. Then also: what about the last padded frame? To me it seems more practical to keep the mp3 stream as it is, but just provide the decoder with exact info on where to begin, and where to end. The point is that even with an added tag, we can't ensure the delay to be reduced in any mp3 decoder, but when reducing the encoder delay, the final delay after decoding could be reduced in every mp3 player. It's right that it will lower the quality of the first frame, but it's very short. I don't remenber the exact of the quality reduction, but Mark mentionned it once on this mailing list. Regards -- Gabriel Bouvigne - France www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] offtopic, decoder comparisons ... possible AE4 bug
Many people have sworn sonique sounds best. I'm guilty too. But if two other decoders agree and sonique disagrees, what does that mean... ? John Beeing the best sounding does not means beeing the most mp3 compliant. Perhaps some extra tricks can be done for improving the sound quality, but conducting to some differences from the output of other decoders. However, there are some bugs in ae4 as Sonique 1.51 fails to the 100Hz test Regards, Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] free format bitstreams and iso documentation
According to my ISO doc (section 2.4.2.3), for layer III, decoders are not required to support higher free format higher than 320kbps. So free format is not restricted to =320kbps. And decoders must support free format at least up to 320k. My ISO 13818-3 documentation : Section 2.4.2.3 "The decoder is not required to support bitrates higher than 256 kbit/s, 160 kbit/s, 160 kbit/s in respect to Layer I, II and III when in free format mode." And in 2.1.74 : "2.1.74 free format [audio]: Any bitrate other than the defined bitrates that is less than the maximum valid bitrate for each layer." You're reading the mpeg-2 doc. That's why you get lower limits. But your doc only indicates the maximum bitrate that decoders are required to support, and does not mention a limit for encoders. Regards, Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
