Re: [MP3 ENCODER] normalization
I'm currently doing a simple command-line program to do it, using libsndfile. It will also trim files (remove blank in the beginning and end) and adjust DC offset. I'll publish the source when it reaches alpha state. - Original Message - From: "Francois du Toit" [EMAIL PROTECTED] To: "Lame MP3 Encoder Mailing List" [EMAIL PROTECTED] Sent: Tuesday, September 05, 2000 2:21 AM Subject: [MP3 ENCODER] normalization I want to implement a normalizing routine in one of my programs, can anybody recommend one? It would be for 16 bit CD audio. Would simply multiplying by a constant factor and rounding be good enough or would the rounding errors cause some problems sorry for the offtopic Francois -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the -mx mode - different philosophy
Frank Klemm wrote: :: -md is not documented. :: :: What is it ? Does anyone made a dual channel mode? :: :: It's like -ms, but no bitrate balance is possible between the channels (maybe also for the main purpose, dual language, a disadvantage from the quality aspect) and also a hint for the decode to only decode one (selectable) channel. Main advantage is the lower CPU usage. Just to clarify : -md is "dual channel" ? David Balazic -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBR, distortion, and CBR
Frank Klemm wrote: :: This is a little bit problematic, because the number of distorted :: bands does not tell you the weight of distortions you will get. :: What do you think sounds uglier: ::20 distorted bands, each 0.1 dB :: or :: 1 distorted band by 2 dB :: ??? :: :: I would say that 20 distorted bands at 0.1dB is preferable, and assume :: that this is the choice of lame's algorithms. Is this assumption wrong ? :: Yes and no. That depends on the distortion of the undistorted bands. Also undistorted bands have an distortion, it is negative. You are saying : "has a distortion" != "is distorted" ? First you need a table of the probability to hear distortions: distortion probability error noise [d=dB] [p=%] [i] -1050.0 0. -3 50.8 0.0004 -2.5 52.0 0.0025 -2 53.2 0.0064 -1.5 55.6 0.020 -1 57.9 0.040 -0.5 63.3 0.116 -0.25 66.3 0.176 0 70.2 0.281 isn't 0 dB distortion == no distortion ? How can it be heared ? +0.1 72.2 0.336 +0.2 74.2 0.422 +0.3 76.1 0.504 +0.4 78.0 0.593 +0.5 80.0 0.706 +1 87.1 1.28 +1.5 93.7 2.34 +2 97.2 3.65 +2.5 99.0 5.43 +3 99.8 8.4 +3.5 99.9 9.5 [ snip ] Sorry if this is an "reader IQ too low" error :-) David Balazic -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] normalization
Addition : I currently use a Windows shareware to do that. It's called 'WaveTrim' (or 'WavTrim') and works fine. I'm currently doing a simple command-line program to do it, using libsndfile. It will also trim files (remove blank in the beginning and end) and adjust DC offset. I'll publish the source when it reaches alpha state. - Original Message - From: "Francois du Toit" [EMAIL PROTECTED] To: "Lame MP3 Encoder Mailing List" [EMAIL PROTECTED] Sent: Tuesday, September 05, 2000 2:21 AM Subject: [MP3 ENCODER] normalization I want to implement a normalizing routine in one of my programs, can anybody recommend one? It would be for 16 bit CD audio. Would simply multiplying by a constant factor and rounding be good enough or would the rounding errors cause some problems sorry for the offtopic http://www..org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Please stop breaking LAME... ;)
Mark Taylor wrote: Hi Everyone, I haven't been keeping up with things for the last week, because my wife and I just had our first baby :-) (baby's requisite website: www.wildpuppy.com/baby) Hey! Congrats, Mark! Give my regards to the new mother too. How are they doing? I only wish I knew more about the lil one cos your website seems to be currently down, along with www.sulaco.org But anyway take care and all the best : ) Regards Jason -- 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] lame source C++ compatible?
Howdy, How to compile lame on a system where only a C++ compiler is available (the C compiler costs extra money)? Currently lame generates nearly uncountable errors with a C++ compiler. I'm having a similar problem trying to compile LAME for my system, for which only a BASIC compiler is available... It seems like practically every line generates an error or warning of some sort?!? Can someone address this? Thanks in advance, Alex -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Frank's coherence [off topic?]
Howdy Gabriel, Am I the only one wich doesn't understand what Frank is telling? Can anyone explain a little? You are not alone. Once I get past his aggressively authoritative posting style (which is a major disincentive to understanding for me), I find I understand about half of what Frank posts. (Some of which seems actually both relevant _and_ useful.*) This is not one of those postings. I assume he has some theoretical basis for wanting to correlate differentiated signals (rather than raw signals), and that this is somehow relevant to LAME (I haven't grepped through the source, but I remember hearing some discussion of a correlator being used for joint switching?), but, since he mentions neither before reeling off a long tabulation of statistics, it all seems pretty out of the blue to me, too. Perhaps a better question would be: Does anyone actually understand what Frank is _saying_ (not tell), and would they care to enlighten the rest of us? Alex *A lot of Frank's commentary seems to point to (possibly) radical areas for improvement. (Case in point - that rant about dithering, which would be fairly difficult to incorporate [as dither noise shaping would have to be integrated into the encoder distortion calculations as well as the decoder], but potentially very useful. Also, the bit about probabilistically measuring the 'distortion of the undistorted bands' - I want to check out that paper.) But a similar amount seems clueless, useless, or counterproductive. (For instance, single-handedly taking on the task of making LAME C++ compatible, when no one else has expressed any desire for it, and when it means massive diffs against the original - no coder with any experience working on a major project _with other people_ would ever do this lightly.) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Frank's coherence [off topic?]
[EMAIL PROTECTED] schrieb am Die, 05 Sep 2000: Howdy Gabriel, Am I the only one wich doesn't understand what Frank is telling? Can anyone explain a little? You are not alone. Once I get past his aggressively authoritative posting style (which is a major disincentive to understanding for me), I find I understand about half of what Frank posts. (Some of which seems actually both relevant _and_ useful.*) This is not one of those postings. I assume he has some theoretical basis for wanting to correlate differentiated signals (rather than raw signals), and that this is somehow relevant to LAME (I haven't grepped through the source, but I remember hearing some discussion of a correlator being used for joint switching?), but, since he mentions neither before reeling off a long tabulation of statistics, it all seems pretty out of the blue to me, too. Perhaps a better question would be: Does anyone actually understand what Frank is _saying_ (not tell), and would they care to enlighten the rest of us? Alex Alex, if you remember Frank's post about DC offsets, there he attached a little C program to calculate AC/DC offsets as well as a correlation between left and right channels. (was around 00/08/05) I plugged into LAME that correlation test for a single frame. If you define RH_VALIDATE_MS at compile time this code gets active. Actually the decision whether to use L/R or M/S coding is based on masking relations. But sometimes LAME switches to M/S coding where L/R coding would be using fewer bits. The extra code you can enable with above defined will try to get a rough estimation on the correlation of left and right channels and will consider the perceptual entropy to check if it would be better not to switch to M/S coding. Ciao Robert PS: www.kraftwerk.de -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] lame source C++ compatible?
[EMAIL PROTECTED] schrieb am Die, 05 Sep 2000: Howdy, How to compile lame on a system where only a C++ compiler is available (the C compiler costs extra money)? Currently lame generates nearly uncountable errors with a C++ compiler. I'm having a similar problem trying to compile LAME for my system, for which only a BASIC compiler is available... It seems like practically every line generates an error or warning of some sort?!? Can someone address this? Thanks in advance, Alex You have a BASIC compiler compiling C code?? OK, just a joke! I have no problems with GCC. Later on I will check to see what the Intel Compiler will say. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] newbie question
- Original Message - From: "Gabriel Bouvigne" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 05, 2000 9:52 AM Subject: 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 Then i take it's good on all modes .. (CBR,VBR, and even ABR) i won't be using it until it's final though :) 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/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] mpglib compiles once again...
Right, just committed a bunch of (quick and ugly) fixes to mpglib so it should once again compile without spewing errors .. it's probably still completely broken though, I hadn't time to test. Someone should take some time going over mpglib and clean it up abit (Frank, since you broke it, why don't you fix it?) Also possibly fixed a mono-decoding bug in layer1.c?! - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: [MP3 ENCODER] Correlation mid/side
Howdy Robert, Alex, if you remember Frank's post about DC offsets, there he attached a little C program to calculate AC/DC offsets as well as a correlation between left and right channels. (was around 00/08/05) I'm not sure I read those - DC offsets aren't particularly relevant to my current efforts (real-time coding). I plugged into LAME that correlation test for a single frame. If you define RH_VALIDATE_MS at compile time this code gets active. Actually the decision whether to use L/R or M/S coding is based on masking relations. But sometimes LAME switches to M/S coding where L/R coding would be using fewer bits. The extra code you can enable with above defined will try to get a rough estimation on the correlation of left and right channels and will consider the perceptual entropy to check if it would be better not to switch to M/S coding. Ah. So LAME uses (or can use) multiple criteria for switching. I'm in the process of adding mid/side to my encoder now, and have just put in a first pass based on what the ISO spec 'specifies' (OK - suggests? hints at?) in Appendix G. Their switching criterion seems particularly random and strange: it is based on a comparison of the sum and difference of the squared energies of the two channels: sum(rl[i]^2 - rr[i]^2) 0.8 * sum(rl[i]^2 + rr[i]^2) Summing 0=i512, where rl and rr are supposedly the energies (so that they are squaring the energy?!?) of the FFT line spectra. (I suspect that they meant to have an absolute value around the difference term.) I don't think this works very well, and I'm not sure why they thought it would work (i.e. what its theoretical basis was), so I'm thinking of substituting a correlator. Do you know why one would correlate on the differential instead of the signal? Also, does anyone know the basis for the ISO switching criterion? Do they really mean square energy (quadrupled magnitude)? They give no hints as to how to reconcile the mid/side samples with the right/left psychoacoustics in the loop section of the encoder. Computing psychoacoustics for the sum and difference signals makes no sense to me, as one is never going to listen to them and thus the psychoacoustic threshold figures are irrelevant, but the alternative of trying to simultaneously allocate bit/noise for both channels seems overly complicated/possibly impossible (oxymoron strikes!). I'm compromising right now by just calculating the distortion thresholds using the L/R SMR and the M/S signal and bandwidths (and the loop distortions with the M/S signal), but this seems like a pretty silly way to do things, and it doesn't sound very good. I'm trying not to plagiarize LAME (I still use the ISO/ATT psych model, for one), but I gather that LAME does some sort of mid/side psychoacoustic processing? Thanks for any feedback/assistance, Alex -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame source C++ compatible?
Now wouldn't a run at compile time mp3 encoder be awesome?? I actually know BASIC, maybe I'll try it, I bet it will be just as good as the sample nibbles code for QBASIC... Yeah, or maybe the NES emulator. ;-) It's REALLY fast, yeah! Josh - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 05, 2000 10:57 AM Subject: RE: [MP3 ENCODER] lame source C++ compatible? Howdy, How to compile lame on a system where only a C++ compiler is available (the C compiler costs extra money)? Currently lame generates nearly uncountable errors with a C++ compiler. I'm having a similar problem trying to compile LAME for my system, for which only a BASIC compiler is available... It seems like practically every line generates an error or warning of some sort?!? Can someone address this? Thanks in advance, Alex -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] ABR 320?
:: would it be possible to encode an mp3 at ABR 320 using frames larger :: than 320 kbps? :: e.g. 440kbps , 560kbps :: 560 kbps result in distortions. 551 kbps is the last without heavy artefacts. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] normalization
On Tue, Sep 05, 2000 at 02:21:45AM +0200, Francois du Toit wrote: I want to implement a normalizing routine in one of my programs, can anybody recommend one? It would be for 16 bit CD audio. Would simply multiplying by a constant factor and rounding be good enough or would the rounding errors cause some problems Rounding cases problems, especially on high quality/low noise audio. The simpliest way is to add 0.75 LSB triangle noise before rounding. -- Frank Klemm -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] normalization
Even working with floats ??? What is the LSB in this case ? - Original Message - From: "Frank Klemm" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 05, 2000 9:23 AM Subject: Re: [MP3 ENCODER] normalization | On Tue, Sep 05, 2000 at 02:21:45AM +0200, Francois du Toit wrote: | I want to implement a normalizing routine in one of my programs, can | anybody recommend one? It would be for 16 bit CD audio. | | Would simply multiplying by a constant factor and rounding be good enough | or would the rounding errors cause some problems | | Rounding cases problems, especially on high quality/low noise audio. | | The simpliest way is to add 0.75 LSB triangle noise before rounding. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame source C++ compatible? (off topic)
Nibbles ? One of my favorite games !! - Original Message - From: "Joshua Bahnsen" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 05, 2000 7:31 PM Subject: Re: [MP3 ENCODER] lame source C++ compatible? | Now wouldn't a run at compile time mp3 encoder be awesome?? I actually know | BASIC, maybe I'll try it, I bet it will be just as good as the sample | nibbles code for QBASIC... Yeah, or maybe the NES emulator. ;-) It's REALLY | fast, yeah! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib compiles once again...
:: Right, just committed a bunch of (quick and ugly) fixes to mpglib so it should :: once again compile without spewing errors .. it's probably still completely :: broken though, I hadn't time to test. :: :: Someone should take some time going over mpglib and clean it up a bit (Frank, :: since you broke it, why don't you fix it?) :: I had to present a lecture on Tuesday from 11:00 to 13:00. So I had no time in the last 36 hours. Layer I now seems to work. Is there a simple Layer I coder out there to test Layer I decoding? I've never have seen a Layer I file. :: :: Also possibly fixed a mono-decoding bug in layer1.c?! :: Fixed. First I tried to print out the Layer I/II/III file format (download of Staroffice was necessary). Guessing is really not my strength. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] VBR, distortion, and CBR
:: :: This is a little bit problematic, because the number of distorted :: :: bands does not tell you the weight of distortions you will get. :: :: What do you think sounds uglier: :: ::20 distorted bands, each 0.1 dB :: :: or :: :: 1 distorted band by 2 dB :: :: ??? :: :: :: :: I would say that 20 distorted bands at 0.1dB is preferable, and assume :: :: that this is the choice of lame's algorithms. Is this assumption wrong ? :: :: :: Yes and no. :: :: That depends on the distortion of the undistorted bands. Also undistorted :: bands have an distortion, it is negative. :: :: You are saying : "has a distortion" != "is distorted" ? :: distorted bands:threshold noise undistorted bands: 0 = noise = threshold So calculate: distortion[dB] = 20 dB * lg (noise/threshold) distorted bands:distortion 0 dB undistorted bands: distortion 0 dB zero distortion bands: distortion = -oo dB (very unlikely that this happens) Noise and threshold are voltages (no power, otherwise multiply by 10 dB). The distortion = max ( x1, ..., xn) model implies an infinite sharp transition of the distortion reception. But reality is far beyond from this model. :: First you need a table of the probability to hear distortions: :: :: distortion probability error noise voltage ratio :: [d=dB] [p=%] [i] :: -1050.0 0. 0.316 : 1 :: -3 50.8 0.0004 0.708 : 1 :: -2.5 52.0 0.0025 0.750 : 1 :: -2 53.2 0.0064 0.794 : 1 :: -1.5 55.6 0.020 0.841 : 1 :: -1 57.9 0.040 0.891 : 1 :: -0.5 63.3 0.116 0.944 : 1 :: -0.25 66.3 0.176 0.972 : 1 ::0 70.2 0.281 1.000 : 1 :: :: isn't 0 dB distortion == no distortion ? :: How can it be heared ? :: No: distortion == threshold. Decibel (dB) is a logarithmic unit. Zero distortion means -oo dB (oo stands for infinite), tenth voltage -20 dB, half voltage -6 dB, equal voltage +/-0 dB, double voltage +6 dB. Do you know Graham Bell? :: +0.1 72.2 0.336 1.011 : 1 :: +0.2 74.2 0.422 1.023 : 1 :: +0.3 76.1 0.504 1.035 : 1 :: +0.4 78.0 0.593 1.047 : 1 :: +0.5 80.0 0.706 1.059 : 1 :: +1 87.1 1.281.122 : 1 :: +1.5 93.7 2.341.189 : 1 :: +2 97.2 3.651.259 : 1 :: +2.5 99.0 5.431.334 : 1 :: +3 99.8 8.4 1.412 : 1 :: +3.5 99.9 9.5 1.496 : 1 :: Search also for "masking_lower" in "lame.c". -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[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. 1st pass with "--hintfile": WAV ---| |--- MP3 (first pass quality) | LAME | | |--- HINT 2nd pass with "--usehintfile" WAV | |--- MP3 (first pass quality) | LAME | HINT --| |--- HINT (unused) In the hint file for instance one byte per frame is stored: Bit 7:4 Should MS or LR coding be used? 0 no info 1 very strong buy for LR stereo br(LR) = 0.545 br(MS) ... 8 no differce br(LR) == br(MS) ... 15 very strong buy for MS stereo br(LR) = 1.834 br(MS) Bit 3:0 Bitrate demand for the best coding 0 no info 1 low bit rate demand 20% ... 5 normal bit rate demand 100% ... 15 very high bit rate demand 300% MS/LR switching can be optimized in a seconds pass. Also the bit reservoir can be better balanced. You can empty the bit reservoir for an attack if there are following some silent milliseconds of music 5 5 5 8 10 3 2 4 4 3 4) ^ empty bit pool here for best Q But may be the attack is followed by a much more worse attack 5 5 5 8 10 14 3 2 4 4 3 4 ^ ^ | empty the bit pool here and not here The same efect can be achieved by increasing the latency time of lame so lame can see more of the music' future. Proposal Application feed samples via lame_encode_buffer() to lame. lame collects the samples in an overlapping circular buffer°) with an size of for instance 8192 samples. Every function (gpsycho, lame encoder, MS/LR detection, ...) gets the same big data block, but everyone are interested of another area of the data: |--| MS/LR ^^^ gpsycho ^^ coder ^ coder (out of bit scenario) -- Mit freundlichen Grüßen Frank Klemm °) circular overlapping buffer Two successive buffers are filled with the same data. | 1 2 3 4 5 6 7 8||1 2 3 4 5 6 7 8| || | 9 10 3 4 5 6 7 8||9 10 3 4 5 6 7 8| || | 9 10 11 12 13 6 7 8||9 10 11 12 13 6 7 8| || Advantage: No wrapping Disadvantage: Needs some 10^-2 MByte of RAM eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] the -mx mode - different philosophy
[Charset iso-8859-2 unsupported, filtering to ASCII...] :: Frank Klemm wrote: :: :: :: -md is not documented. :: :: :: :: What is it ? Does anyone made a dual channel mode? :: :: :: :: :: It's like -ms, but no bitrate balance is possible between the channels :: (maybe also for the main purpose, dual language, a disadvantage from the :: quality aspect) and also a hint for the decode to only decode one :: (selectable) channel. :: :: Main advantage is the lower CPU usage. :: :: Just to clarify : -md is "dual channel" ? :: Yes: Bit 7,6 of the MPEG frame header: 00 LR Stereo frame(Stereo, Left + Right Channel, bit balancing possible) 01 MS Stereo frame(Stereo, Mid- and Side Signal) 10 Dual Channel frame (Mono, for instance dual language english/german) 11 Single Channel frame (Mono) Ist it right that Layer II MS-Frames are unable to NOT use intensity stereo for f fs/4 (for CD 11 kHz)? -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Correlation mid/side
:: :: Also, does anyone know the basis for the ISO switching criterion? Do they :: really mean square energy (quadrupled magnitude)? They give no hints as to :: how to reconcile the mid/side samples with the right/left psychoacoustics in :: the loop section of the encoder. Computing psychoacoustics for the sum and :: difference signals makes no sense to me, as one is never going to listen to :: them and thus the psychoacoustic threshold figures are irrelevant, but the :: alternative of trying to simultaneously allocate bit/noise for both channels :: seems overly complicated/possibly impossible (oxymoron strikes!). I'm :: compromising right now by just calculating the distortion thresholds using :: the L/R SMR and the M/S signal and bandwidths (and the loop distortions with :: the M/S signal), but this seems like a pretty silly way to do things, and it :: doesn't sound very good. I'm trying not to plagiarize LAME (I still use the :: ISO/ATT psych model, for one), but I gather that LAME does some sort of :: mid/side psychoacoustic processing? :: 1st step: - Calculate diffuse field corrected ear-drum SPL°): L' = a(w) L + b(w) R, R' = a(w) R + b(w) L w is a small omega, a(w),b(w) complex Note: different for loudspeakers and head phones (where a \approx 1 and b \approx 0) Note: search for HRTF to get usable approaches for a and b. Note: for very good results you must take into consideration that a and b changes depending on the temporal direct/indirect sound ratio - ignore in-brain talk over (ca. -60 dB @1 kHz, much lower than accoustic talk over) - calculate threshold for the left and the right ear 2nd step: if frame can be coded in LR mode - code L using L and threshold(L) - code R using R and threshold(R) if frame can be coded in MS mode - code M using M and 0.6...0.8 * min(threshold(L),threshold(R)) - code S using S, decoded coded M, threshold(L) and threshold(R) 3rd step: select MS/LR depending on: - br(MS)/br(LR) ratio - the past of the audio file - bit pool fuel - (the future of the audio file using one mechanism I mailed before) - user options? -- Mit freundlichen Grüßen Frank Klemm °) SPL = Sound preasure level eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Robert Hegemann @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] presets Dated: 01 Sep 00 09:48:58 [processed here: 05 Sep 00 14:12:44] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: bob ef9108d3 @REPLY: fuchs.offl.uni-jena.de d051582a @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: KMail [version 1.0.29.2] @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01859 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:14:17 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id LAA30444 for mp3encoder-list; Fri, 1 Sep 2000 11:38:49 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by geek.rcc.se (8.8.4/8.7.3) with SMTP id LAA30438 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 11:38:43 +0200 @RFC-Received: (qmail 13116 invoked by uid 0); 1 Sep 2000 09:42:25 - @RFC-Received: from pec-66-32.tnt4.me.uunet.de (HELO bob) (149.225.66.32) by mail.gmx.net with SMTP; 1 Sep 2000 09:42:25 - @RFC-Content-Type: text/plain @RFC-References: [EMAIL PROTECTED] @RFC-In-Reply-To: [EMAIL PROTECTED] @RFC-MIME-Version: 1.0 @RFC-Message-Id: 00090111211600.00422@bob @RFC-Content-Transfer-Encoding: quoted-printable @RFC-Sender: [EMAIL PROTECTED] From: Robert Hegemann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Frank Klemm schrieb am Don, 31 Aug 2000: :: b) LAME's filter is not much useful for highpass filtering :: External filters are available. For integration the f*cking "signed short int" format must be replaced by "float" or "double". I've heared (by listening) that the lame FIR high pass filter is not very well. Extern 4th order butterworth filter are working much better. They also can be used for Hifi highpass filtering (fu=30 Hz for records). LAME has FIR filters? I thought it works on the polyphase filter bank where you have 32 equidistant controlers. Good filters would be nice to have, go for it... :: c) when you resample and want to lowpass, try to get rid off sfb21! :: Can you explain this? long blocks have 22 scalefactor bands 0...21. But for sfb21 there are no masking ratios and it will not be transmitted. So you cant color that band, means you cannot adjust the quantizer stepsize for it. (short blocks: 13 bands sfb12 will not be transmitted). I meant, if you want a resulting bandwidth of x kHz, try to select a outsamplerate where this does not interfere with sfb21 (short sfb12). Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:14 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Holger Dors @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re[2]: [MP3 ENCODER] RazorLame 1.1.0 released Dated: 01 Sep 00 10:24:45 [processed here: 05 Sep 00 14:12:45] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: kittelberger.de aa0c30c1 @REPLY: cybercable.fr 66bb3f2e @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: The Bat! (v1.45 S/MIME) @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01866 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:14:28 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id KAA30092 for mp3encoder-list; Fri, 1 Sep 2000 10:20:43 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from gallileo.kittelberger.net (gallileo.kittelberger.net [62.192.3.52]) by geek.rcc.se (8.8.4/8.7.3) with SMTP id KAA30089 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 10:20:38 +0200 @RFC-Received: (qmail 18868 invoked from network); 1 Sep 2000 08:25:56 - @RFC-Received: from ns.kittelberger.net (HELO seven.kittelberger.intra) (62.192.3.24) by gallileo.kittelberger.net with SMTP; 1 Sep 2000 08:25:56 - @RFC-X-Priority: 3 (Normal) @RFC-Message-ID: [EMAIL PROTECTED] @RFC-In-reply-To: 002101c013dd$b1dc9f60$[EMAIL PROTECTED] @RFC-References: [EMAIL PROTECTED] 002101c013dd$b1dc9f60$[EMAIL PROTECTED] @RFC-Sender: [EMAIL PROTECTED] From: Holger Dors [EMAIL PROTECTED] To: Steve Lhomme [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Hello Steve, Yep, and I personnaly use a lame EXE with libnsdfile support, so not only wav files are supported ! if you feel a bit adventurous, take a look at RazorLame.dat and look for the section "InputFileTypes". You can add more file types there, so if you know your LAME supports more, add them there! (I'd suggest making a copy of the file though; if you ruin this file RazorLame won't work properly any more) Regards, Holger Dors mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:14 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Robert Hegemann @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] Encoding 44.1 kHz as 48 kHz sounds not so very well Dated: 01 Sep 00 11:21:26 [processed here: 05 Sep 00 14:12:43] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: bob 277b0275 @REPLY: fuchs.offl.uni-jena.de 960660e9 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: KMail [version 1.0.29.2] @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01851 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:14:12 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id LAA30448 for mp3encoder-list; Fri, 1 Sep 2000 11:38:51 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by geek.rcc.se (8.8.4/8.7.3) with SMTP id LAA30441 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 11:38:44 +0200 @RFC-Received: (qmail 13159 invoked by uid 0); 1 Sep 2000 09:42:26 - @RFC-Received: from pec-66-32.tnt4.me.uunet.de (HELO bob) (149.225.66.32) by mail.gmx.net with SMTP; 1 Sep 2000 09:42:26 - @RFC-Content-Type: text/plain @RFC-References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @RFC-In-Reply-To: [EMAIL PROTECTED] @RFC-MIME-Version: 1.0 @RFC-Message-Id: 00090111230101.00422@bob @RFC-Content-Transfer-Encoding: quoted-printable @RFC-Sender: [EMAIL PROTECTED] From: Robert Hegemann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Frank Klemm schrieb am Fre, 01 Sep 2000: Why a quadratic interpolation is used for upsampling instead of a sinc interpolator? -- Frank Klemm I can't answer your question, but where is upsampling from 44.1 to 48 kHz good for? Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:14 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Roel VdB @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re[3]: [MP3 ENCODER] RazorLame 1.1.0 released Dated: 01 Sep 00 03:18:24 [processed here: 05 Sep 00 14:12:47] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: yucom.be a7b25a3b @REPLY: kittelberger.de 364f56da @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: The Bat! (v1.45) Business @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01907 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:15:24 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id DAA29206 for mp3encoder-list; Fri, 1 Sep 2000 03:15:01 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from apoq.skynet.be (apoq.skynet.be [195.238.2.35]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id DAA29203 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 03:15:00 +0200 @RFC-Received: from dialup352.gent.skynet.be (dialup352.gent.skynet.be [195.238.17.96])by apoq.skynet.be (Postfix) with ESMTP id 2EF5D98E3 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 03:19:16 +0200 (MET DST) @RFC-X-Priority: 3 (Normal) @RFC-Message-ID: [EMAIL PROTECTED] @RFC-In-reply-To: [EMAIL PROTECTED] @RFC-References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @RFC-Sender: [EMAIL PROTECTED] From: Roel VdB [EMAIL PROTECTED] To: Holger Dors [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Hello Holger, Thursday, August 31, 2000, 2:31:48 PM, you wrote: HD It's hard to come up with a good option dialog for RL, given the vast HD amount of options LAME has to offer. I think it's a good idea to put HD those settings in categories, however, I agree, it can get a bit HD unclearly... I think this is not good way of handling things. If there are too much options, there are too much options. If you decide to catalog some of them as "advanced", some as "expert" and other with another subjective label, it only complicates things even further. 30 options in 1 screen are less complicated than 30 options scattered over 5 screens. What I suggest, since lame will continuously develop and new options will be added, is to simply handle things like this: - 1 screen (oversight clarity) - in top, a (greyed out or so) continuous display of current command line. I never understood why enabling this is an option. - only a limited set of "core" options. stereo mode, bitrate, encoder mode, delete after, and the most common flags. Just so you have a nice oversight of options. - a box to add non-common command line options. - a flag to make lame only use that box, instead of adding the content to current selected options. This is, basically, the way lamebatch did things. In the long run this seems to be the only managable way of constructing a frontend imho: You simply see what's set, and you don't need to look 3 windows back for some setting you also might need. then, why no multithread? it'd be nice to update the to-be-encoded list in one window while the encoding-box is somewhere else... I had to press abort too often :( just some suggestions ... -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:15 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING ***
*
* The e-mail-message appended below is list- or mailserver-related
*
* That type of mail will by definition not be processed on this system
* and in general is not accepted in the fidonet.org-domain.
*
* To avoid these bouncings the listkeeper is kindly requested to
* remove any subscription coming from a z2.fidonet.org-style address.
*
*If you have reason to believe your message was removed without due
* reason then kindly inform '[EMAIL PROTECTED]'.
*
From: Mathew Hendry @2:292/862
To:Sergey Sapelin @2:5020/1844.33
Subj.: Re: [MP3 ENCODER] lame source C++ compatible?
Dated: 02 Sep 00 02:48:11
[processed here: 05 Sep 00 14:13:39]
@TOPT 33
@INTL 2:5020/1844 2:292/862
@MSGID: carla 3d294f4f
@REPLYADDR: [EMAIL PROTECTED]
@REPLYTO: 2:292/862@fidonet UUCP
@PID: Microsoft Outlook Express 5.00.3018.1300
@CHRS: LATIN-1 2
@RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212])
by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA03131 for
[EMAIL PROTECTED]; Sat, 2 Sep 2000 02:59:33 +0200
@RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id
CAA00334 for mp3encoder-list; Sat, 2 Sep 2000 02:43:55 +0200
@RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to
[EMAIL PROTECTED] using -f
@RFC-Received: from hose.pipex.net (hose.mail.pipex.net [158.43.128.58]) by
geek.rcc.se (8.8.4/8.7.3) with ESMTP id CAA00331 for [EMAIL PROTECTED];
Sat, 2 Sep 2000 02:43:54 +0200
@RFC-Received: from carla (usercb92.uk.uudial.com [62.188.151.5]) by
hose.pipex.net (Postfix) with SMTP id 7F25E4505 for [EMAIL PROTECTED];
Sat, 2 Sep 2000 01:47:52 +0100 (BST)
@RFC-Message-ID: 001401c01477$89e90f30$23f26ac3@carla
@RFC-References: [EMAIL PROTECTED]
@RFC-X-Priority: 3
@RFC-X-MSMail-Priority: Normal
@RFC-Sender: [EMAIL PROTECTED]
From: "Mathew Hendry" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
From: "Segher Boessenkool" [EMAIL PROTECTED]
How to compile lame on a system where only a C++ compiler is available
(the
C compiler costs extra money)? Currently lame generates nearly
uncountable
errors with a C++ compiler.
Put
extern "C" {
}
around everything? (Around a whole file is ok, I believe).
That only affects the linkage of functions (e.g. disables name mangling).
There's no easy way to do it in general. I've done it a few times for some
fairly large pieces of code, and it's no fun at all. Then there's the
maintenance...
Is the C compiler expensive? :)
-- Mat.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
@Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:59 (2.14-tx8.10)
@Via D'Bridge 1.58 2:292/854 09/05 14:04
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: David Balazic @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] RazorLame 1.1.0 released Dated: 01 Sep 00 09:54:38 [processed here: 05 Sep 00 14:12:45] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: uni-mb.si 7575c603 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: Mozilla 4.75 [en] (WinNT; U) @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01871 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:14:41 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id JAA29976 for mp3encoder-list; Fri, 1 Sep 2000 09:50:44 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from rcum.uni-mb.si (rcum.uni-mb.si [164.8.2.10]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id JAA29973 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 09:50:34 +0200 @RFC-Received: from uni-mb.si (rcum.uni-mb.si [164.8.2.10]) by rcum.uni-mb.si (PMDF V5.2-32 #45903) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Fri, 1 Sep 2000 09:54:41 MET @RFC-Message-id: [EMAIL PROTECTED] @RFC-X-Accept-Language: en @RFC-References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @RFC-Sender: [EMAIL PROTECTED] From: David Balazic [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Holger Dors wrote: Hello David, For VBR mode the max bitrate is set on one screen, while min bitrate on the other. Confusing. Yes, I know, and I'm open to any suggestions. But I'm not even supporting all switches now, e.g. free bitrates are still missing, as well as the presets aren't available. If someone does come up with a layout of a new option screen, I'd be willing to implement that in an upcoming version. (If I believe that it's better, of course, and it's not too hard to implement.) Also when ABR is selected, the max bitrate slider should be turned off. I disagree. According to the help, it's "NOT RECOMMENDED", but after all it is possible. Oh, didn't know that. But I noticed that the -B option is not present in the command line ! ( according to the "Show LAME commands:" button , shouldn't that be "show used LAME options:" ? ) An idea for the layout : put the min and max VBR bitrate slider on the same screen ! Why is the ABR bitrate not a slider ? With the option of manual number entry maybe. Who am I to say to the user that he cannot do this when he knows that it's possible? ;-) Regards, Holger Dors mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:14 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: [EMAIL PROTECTED] @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: [MP3 ENCODER] MLame Help Requested Dated: 02 Sep 00 09:40:23 [processed here: 05 Sep 00 14:14:53] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: c3p0. de0ba4c5 @REPLY: c3p0. 377a4b56 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: Microsoft Innerbutt Exploder 5.0 @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id QAA09486 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 16:53:57 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id JAA00994 for mp3encoder-list; Sat, 2 Sep 2000 09:36:34 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from eagle.vnweb.com (corp.vnweb.com [209.247.80.2]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id JAA00991 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 09:36:32 +0200 @RFC-Received: from c3p0 ([208.194.173.34]) by eagle.vnweb.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S1V35) with SMTP id com for [EMAIL PROTECTED]; Sat, 2 Sep 2000 00:38:06 -0700 @RFC-Message-ID: 2902.7402300@c3p0. @RFC-In-Reply-To: 2901.21460400@c3p0. @RFC-References: [EMAIL PROTECTED] 00090111211600.00422@bob 2901.21460400@c3p0. @RFC-X-Priority: 3 (Normal) @RFC-Sender: [EMAIL PROTECTED] From: [EMAIL PROTECTED] ([EMAIL PROTECTED]) To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] I'm encoding MP3 - MP3. How do you keep MLAME from adding and extra ".mp3" to the file name? Brent -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 16:54 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Steve Lhomme @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] Please stop breaking LAME... ;) Dated: 02 Sep 00 09:04:54 [processed here: 05 Sep 00 14:14:54] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: cybercable.fr 2ca3b9be @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: Microsoft Outlook Express 5.50.4133.2400 @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id QAA09493 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 16:54:04 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id JAA00878 for mp3encoder-list; Sat, 2 Sep 2000 09:05:33 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from camus.cybercable.fr (camus.cybercable.fr [212.198.0.200]) by geek.rcc.se (8.8.4/8.7.3) with SMTP id JAA00875 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 09:05:31 +0200 @RFC-Received: (qmail 9446991 invoked from network); 2 Sep 2000 07:06:37 - @RFC-Received: from r182m156.cybercable.tm.fr (HELO pc) ([195.132.182.156]) (envelope-sender [EMAIL PROTECTED]) by camus.cybercable.fr (qmail-ldap-1.03) with SMTP for [EMAIL PROTECTED]; 2 Sep 2000 07:06:37 - @RFC-Message-ID: 001b01c014ac$295f0f40$[EMAIL PROTECTED] @RFC-References: [EMAIL PROTECTED] @RFC-X-Priority: 3 @RFC-X-MSMail-Priority: Normal @RFC-Sender: [EMAIL PROTECTED] From: "Steve Lhomme" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Also it would be nice if you cast types that don't match the functions types into the correct one (or use the correct one to begin with) .. it's both the correct and nice way to do it... I think that casting can be dangerous. It removes some compile errors than can sometimes be an error ! So I think you'd better cast when you know what you're doing, otherwise let the compile error... -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 16:54 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Sigbj°rn Skjµret @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: [MP3 ENCODER] Please stop breaking LAME... ;) Dated: 02 Sep 00 08:48:08 [processed here: 05 Sep 00 14:14:55] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: c2i.net f8f9b585 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: THOR 2.6a (Amiga;TCP/IP) @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id QAA09504 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 16:54:08 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id HAA00660 for mp3encoder-list; Sat, 2 Sep 2000 07:46:29 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from golf.dax.net (golf.dax.net [193.216.69.103]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id HAA00657 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 07:46:28 +0200 @RFC-Received: from mp-217-243-185.daxnet.no (mp-217-243-185.daxnet.no [193.217.243.185]) by golf.dax.net (8.9.3/8.9.3) with SMTP id HAA00891 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 07:50:26 +0200 (MET DST) @RFC-Message-ID: [EMAIL PROTECTED] @RFC-Sender: [EMAIL PROTECTED] From: "Sigbj°rn Skjµret" [EMAIL PROTECTED] To: "Frank Klemm" [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Please check that your code compiles and works ok before checking it in to the CVS .. I've repeatedly had to go fix compile errors in the CVS now... :P Also it would be nice if you cast types that don't match the functions types into the correct one (or use the correct one to begin with) .. it's both the correct and nice way to do it... Also don't set ambigous types like "unsigned", use the proper full name, "unsigned int". And a problem I can't figure out right now is why LAME won't encode at all anymore, it just creates an empty mp3 (that means it atleast opens it), and then quits saying "Error writing mp3, disk full?" .. what have you done? ;) - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 16:54 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Josh Coalson @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] linux lossless encoder Dated: 02 Sep 00 22:22:03 [processed here: 05 Sep 00 14:15:21] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: hotmail.com 3b21f251 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id WAA14782 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 22:42:46 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id WAA02399 for mp3encoder-list; Sat, 2 Sep 2000 22:18:16 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from hotmail.com (f148.law3.hotmail.com [209.185.241.148]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id WAA02396 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 22:18:14 +0200 @RFC-Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 2 Sep 2000 13:22:03 -0700 @RFC-Received: from 209.209.16.29 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 02 Sep 2000 20:22:03 GMT @RFC-X-Originating-IP: [209.209.16.29] @RFC-Mime-Version: 1.0 @RFC-Content-Type: text/plain; format=flowed @RFC-Message-ID: [EMAIL PROTECTED] @RFC-X-OriginalArrivalTime: 02 Sep 2000 20:22:03.0287 (UTC) FILETIME=[74B7B270:01C0151B] @RFC-Sender: [EMAIL PROTECTED] From: "Josh Coalson" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] hello , considering that there isn't a monkeys audio for linux, I don't supose there are any developers out there would like to take a look a shorten to see if it could be improved to match monkeys audio performance , or perhaps even better? :) well, once upon a time there was ogg squish, which was open source, but the source has disappeared (at least I haven't been able to find it). I heard Monty is currently too busy with vorbis to get to the lossless stuff right now, so in the meantime I'm doing just what you mentioned. time is short but when I get something useful I will put up the code. at least with lossless encoding it's not so bad to have an interim solution... when ogg squish comes back at least there will be no generation loss converting. Josh p.s. don't expect radically greater compression ratios though... there is a limit with what you can do with lossless compression. but the format I'm working on will support streaming and sample- accurate seeking, which shorten doesn't. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 22:42 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:07 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Scott manley @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] linux lossless encoder Dated: 02 Sep 00 21:36:17 [processed here: 05 Sep 00 14:15:30] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: myplay.com d85f4766 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i686) @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id XAA15586 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 23:57:57 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id WAA02456 for mp3encoder-list; Sat, 2 Sep 2000 22:31:22 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from ns1.corp.myplay.com ([4.20.166.3]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id WAA02453 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 22:31:19 +0200 @RFC-Received: from myplay.com (drevil.corp.myplay.com [192.168.1.102]) by ns1.corp.myplay.com (8.9.3+Sun/8.9.1) with ESMTP id NAA00191for [EMAIL PROTECTED]; Sat, 2 Sep 2000 13:34:18 -0700 (PDT) @RFC-Message-ID: [EMAIL PROTECTED] @RFC-X-Accept-Language: en @RFC-References: [EMAIL PROTECTED] @RFC-Sender: [EMAIL PROTECTED] From: Scott manley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] well, once upon a time there was ogg squish, which was open source, but the source has disappeared (at least I haven't been able to find it). I heard Monty is currently too busy with vorbis to get to the lossless stuff right now, so in the meantime I'm doing just what you mentioned. time is short but when I get something useful I will put up the code. at least with lossless encoding it's not so bad to have an interim solution... when ogg squish comes back at least there will be no generation loss converting. You should search for a prgaram called 'Shorten' this is also a lossless compressor for Unix (free for unix - but you pay for the windows version) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 23:57 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:07 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Ingo Saitz @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] linux lossless encoder Dated: 02 Sep 00 23:51:59 [processed here: 05 Sep 00 14:15:31] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: studserv.stud.uni-hannover.de 02e2dcfd @REPLY: hotmail.com 3b21f251 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: Mutt/1.2.5i @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id AAA15809 for [EMAIL PROTECTED]; Sun, 3 Sep 2000 00:08:03 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id XAA02661 for mp3encoder-list; Sat, 2 Sep 2000 23:48:07 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from studserv.stud.uni-hannover.de ([EMAIL PROTECTED] [130.75.176.2]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id XAA02658 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 23:48:05 +0200 @RFC-Received: (from ingo@localhost)by studserv.stud.uni-hannover.de (8.11.0/8.11.0/MX/check_local4.1) id e82LpxP06551 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 23:51:59 +0200 (MET DST) @RFC-X-Spam-Filter: [EMAIL PROTECTED] by digitalanswers.org @RFC-Message-ID: [EMAIL PROTECTED] @RFC-Mail-Followup-To: [EMAIL PROTECTED] @RFC-References: [EMAIL PROTECTED] @RFC-Content-Disposition: inline @RFC-In-Reply-To: [EMAIL PROTECTED]; from [EMAIL PROTECTED] on Sat, Sep 02, 2000 at 08:22:03PM + @RFC-Sender: [EMAIL PROTECTED] From: Ingo Saitz [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] MoiN On Sat, Sep 02, 2000 at 08:22:03PM +, Josh Coalson wrote: well, once upon a time there was ogg squish, which was open source, but the source has disappeared (at least I haven't been able to find it). Well, it still seems to be there: http://web.mit.edu/afs/sipb/user/xiphmont/ogg-98.10.tgz Be sure to enable lossless compression with -Q10 or -L No, I didn't test the lossless compression it offers, yet. So have fun playing :) Ingo -- I am the "ILOVEGNU" signature virus. Just copy me to your signature. This email was infected under the terms of the GNU General Public License. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sun Sep 3 2000 at 00:08 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:07 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Sigbj°rn Skjµret @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] Please stop breaking LAME... ;) Dated: 03 Sep 00 07:51:43 [processed here: 05 Sep 00 14:15:57] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: c2i.net 4caaf0f8 @REPLY: fuchs.offl.uni-jena.de b9b0cac3 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: THOR 2.6a (Amiga;TCP/IP) @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id MAA21333 for [EMAIL PROTECTED]; Sun, 3 Sep 2000 12:33:36 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id GAA03432 for mp3encoder-list; Sun, 3 Sep 2000 06:54:12 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from golf.dax.net (golf.dax.net [193.216.69.103]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id GAA03429 for [EMAIL PROTECTED]; Sun, 3 Sep 2000 06:54:10 +0200 @RFC-Received: from mp-217-210-2.daxnet.no (mp-217-210-2.daxnet.no [193.217.210.2])by golf.dax.net (8.9.3/8.9.3) with SMTP id GAA29101 for [EMAIL PROTECTED]; Sun, 3 Sep 2000 06:57:54 +0200 (MET DST) @RFC-In-Reply-To: [EMAIL PROTECTED] @RFC-Message-ID: [EMAIL PROTECTED] @RFC-Sender: [EMAIL PROTECTED] From: "Sigbj°rn Skjµret" [EMAIL PROTECTED] To: "Frank Klemm" [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] :: Please check that your code compiles and works ok before checking it in :: to the CVS ... :: That doesn't help fully to solve the problem. Compiler and runtime libs are different. So the check can only be done for one (or two) compilers. Still, it's not fun when certain files fail to compile because of silly errors (like conflicting prototypes). ;) Currently my aim is, that the program is compilable with: gcc 2.95.2 g++ 2.95.2 I run gcc 2.95.(3) and SAS/C (the latter is usually much more helpful on warnings, and still much more forgiving on "errors")... :: Also it would be nice if you cast types that don't match the functions :: types into the correct one Casting is a bad thing. Correct the reason for the casting, not the warning (or the error in C++) itself. See Ada Rationale. It is Ada related, but the reasons are the same for every procedural language like C, Pascal, Ada, ... Ofcos, as I said, the best thing is to use the correct one to begin with, but if that isn't possible, atleast cast the value into the correct one. - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sun Sep 3 2000 at 12:33 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:07 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Eric Howgate @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: Re[4]: [MP3 ENCODER] RazorLame 1.1.0 released Dated: 03 Sep 00 18:50:45 [processed here: 05 Sep 00 14:16:38] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: home ac3fa0b7 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: Microsoft Outlook Express 5.00.2615.200 @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id TAA25434 for [EMAIL PROTECTED]; Sun, 3 Sep 2000 19:17:31 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id SAA04299 for mp3encoder-list; Sun, 3 Sep 2000 18:54:42 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from tungsten.btinternet.com (tungsten.btinternet.com [194.73.73.81]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id SAA04296 for [EMAIL PROTECTED]; Sun, 3 Sep 2000 18:54:40 +0200 @RFC-Received: from [213.1.66.203] (helo=home) by tungsten.btinternet.com with smtp (Exim 3.03 #83)id 13Vd5y-0004vK-00 for [EMAIL PROTECTED]; Sun, 03 Sep 2000 17:58:14 +0100 @RFC-Message-ID: 003001c015c8$64d1fde0$cb4201d5@home @RFC-References: [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] [EMAIL PROTECTED] @RFC-X-Priority: 3 @RFC-X-MSMail-Priority: Normal @RFC-Sender: [EMAIL PROTECTED] From: "Eric Howgate" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] - Original Message - From: Holger Dors [EMAIL PROTECTED] To: Roel VdB [EMAIL PROTECTED] Sent: Friday, September 01, 2000 12:01 PM Subject: Re[4]: [MP3 ENCODER] RazorLame 1.1.0 released Hello Roel, 30 options in 1 screen are less complicated than 30 options scattered over 5 screens. This can probably be disputed for very long! - 1 screen (oversight clarity) - in top, a (greyed out or so) continuous display of current command line. I never understood why enabling this is an option. - only a limited set of "core" options. stereo mode, bitrate, encoder mode, delete after, and the most common flags. Just so you have a nice oversight of options. - a box to add non-common command line options. - a flag to make lame only use that box, instead of adding the content to current selected options. The problem starts with the "most common flags". Who will define those? You've left out VBR, for a start. Similar, I know at least one person who was very happy about that the "Audio Processing" tab where you can set sampling frequency and filter options. Personally, I started RL because of the many options Lame has to offer, it's fun to play with them, and I wanted an easy interface. I admit that the options dialog is far from being perfect, but I think it's a good start. then, why no multithread? it'd be nice to update the to-be-encoded list in one window while the encoding-box is somewhere else... Actually, this is on my wish list. However, unlike LAME, I'm currently the only programmer in RazorLame (I hope this changes soon!), and the wishlist grows and grows. Additional, I do this in my spare time, so please be patient. Regards, Holger Dors mailto:[EMAIL PROTECTED] Perhaps the 'disputants' might care to take a look at a new front end for Lame, available from http://www.geocities.com/enlamer/ This has many of Lame's options in the one large user dialog, but I suspect it will confuse the novice user (and it seems to be able to handle only single files at present); 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. Roel's site is certainly a good guide for achieving optimal performance with music - but there are other uses, eg voice recording, not touched on there, and only barely mentioned in the 'Usage' file. Eric -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Joshua Bahnsen @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: [MP3 ENCODER] problems decoding with latest CVS version Dated: 01 Sep 00 20:13:41 [processed here: 05 Sep 00 14:12:40] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: ezworks.net 132c51b7 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: Mozilla 4.75 [en] (X11; U; Linux 2.4.0-test8 i586) @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01831 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:13:43 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id UAA31727 for mp3encoder-list; Fri, 1 Sep 2000 20:11:01 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from intelli2.ezworks.net (mail.ezworks.net [63.238.60.5]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id UAA31724 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 20:10:56 +0200 @RFC-Received: from [63.238.61.23] by intelli2.ezworks.net (NTMail 4.30.0013/NU3336.00.61885767) with ESMTP id kdtxhaaa for [EMAIL PROTECTED]; Fri, 1 Sep 2000 14:14:56 -0400 @RFC-Message-ID: [EMAIL PROTECTED] @RFC-X-Accept-Language: en @RFC-Sender: [EMAIL PROTECTED] From: Joshua Bahnsen [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] When using the latest CVS code, I cannot decode mp3s any longer it gives me this error Bitrate 9 kbps not legal for 44100 Hz output sampling This is a 192 kBits 44.1 Stereo mp3. I've tried many different files, all with the same result. Josh -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:13 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: [EMAIL PROTECTED] @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: [MP3 ENCODER] mlame usage without naming .mp3.mp3 Dated: 01 Sep 00 23:46:04 [processed here: 05 Sep 00 14:12:32] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: c3p0. 377a4b56 @REPLY: bob ef9108d3 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: Microsoft Innerbutt Exploder 5.0 @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01671 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:08:58 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id BAA32729 for mp3encoder-list; Sat, 2 Sep 2000 01:51:53 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from eagle.vnweb.com (corp.vnweb.com [209.247.80.2]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id BAA32726 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 01:51:51 +0200 @RFC-Received: from c3p0 ([208.194.173.34]) by eagle.vnweb.com (Post.Office MTA v3.5.3 release 223 ID# 0-12345L500S1V35) with SMTP id com for [EMAIL PROTECTED]; Fri, 1 Sep 2000 14:43:48 -0700 @RFC-Message-ID: 2901.21460400@c3p0. @RFC-In-Reply-To: 00090111211600.00422@bob @RFC-References: [EMAIL PROTECTED] 00090111211600.00422@bob @RFC-X-Priority: 3 (Normal) @RFC-Sender: [EMAIL PROTECTED] From: [EMAIL PROTECTED] ([EMAIL PROTECTED]) To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] How do you get mlame to batch encode MP3-MP3 without adding a ".mp3" to every file; resulting in a file with ".mp3.mp3" as extentions? Brent -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:08 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] normalization
:: Even working with floats ??? :: :: What is the LSB in this case ? :: The LSB is 1 for int's. See "MPEG-2 AAC Stereo Verification Tests" and the item "Glockenspiel was too high". May be this is more comprehensible. :: | On Tue, Sep 05, 2000 at 02:21:45AM +0200, Francois du Toit wrote: :: | I want to implement a normalizing routine in one of my programs, can :: | anybody recommend one? It would be for 16 bit CD audio. :: | :: | Would simply multiplying by a constant factor and rounding be good enough :: | or would the rounding errors cause some problems :: | :: | Rounding cases problems, especially on high quality/low noise audio. :: | :: | The simpliest way is to add 0.75 LSB triangle noise before rounding. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Coding history report for each (non trivial) function
May be evry (non trival function should get a history header? /* * Function: double sinc (IN double x); * * Purpose:calculates sin (pi x) / (pi x) * * Input: * * History: *Person_1 2000-06-02: first version *Person_2 2000-06-12: zero cross error bug removed */ -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] MGDIFF
May be the following file can be added. I use it do quick show differences
of two brances. Quick and dirty, can still be optimized. I named it MGDIFF
and it needs mgdiff.
#! /bin/bash
for i in {*,*/*,*/*/*,*/*/*/*}.{c,h}; do
file1=`pwd`/$i
file2=`echo $file1 | sed s/lame/lame_old/`
if diff -bwB --brief $file1 $file2; then
echo equal $i
else
echo -e "\033[7mDifferent: $i\033[0m"
mgdiff -title "mgdiff $i" -geometry 1536x800 -args "-bw" $file1 $file2
sleep 2
fi
done
--
Mit freundlichen Grüßen
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Frank's coherence [off topic?]
:: :: I plugged into LAME that correlation test for a single frame. :: If you define RH_VALIDATE_MS at compile time this code gets active. :: Actually the decision whether to use L/R or M/S coding is based :: on masking relations. But sometimes LAME switches to M/S coding :: where L/R coding would be using fewer bits. The extra code you :: can enable with above defined will try to get a rough estimation :: on the correlation of left and right channels and will consider :: the perceptual entropy to check if it would be better not to switch :: to M/S coding. :: I've added a remark on this piece of code. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Layer III decoding has been broken between Mo and now
Decoding of Layer 3 doesn't work anymore. Last checkout/commit/checkout in the night So/Mo worked, now it is broken. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Neues File
Ich benötige ein neues File für mlame/mlame.bat mlame_corr.c oder so. mlame soll (auf Wunsch) automatisch zwischen -ms, -mj und -mm umschalten. -- Mit freundlichen Grüßen Frank Klemm eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED] phone | +49 (3641) 64-2721home: +49 (3641) 390545 sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MGDIFF
Frank Klemm schrieb am Mit, 06 Sep 2000:
May be the following file can be added. I use it do quick show differences
of two brances. Quick and dirty, can still be optimized. I named it MGDIFF
and it needs mgdiff.
#! /bin/bash
for i in {*,*/*,*/*/*,*/*/*/*}.{c,h}; do
file1=`pwd`/$i
file2=`echo $file1 | sed s/lame/lame_old/`
if diff -bwB --brief $file1 $file2; then
echo equal $i
else
echo -e "\033[7mDifferent: $i\033[0m"
mgdiff -title "mgdiff $i" -geometry 1536x800 -args "-bw" $file1 $file2
sleep 2
fi
done
I always do
diff -q lame-old/ lame-new/ | grep differ
this shows me all files that differ in lame-old and lame-new folders.
I prefer xxdiff over mgdiff to visualize differences :-)
Ciao Robert
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib compiles once again...
Frank Klemm schrieb am Die, 05 Sep 2000: Layer I now seems to work. Is there a simple Layer I coder out there to test Layer I decoding? I've never have seen a Layer I file. Yes, get the ISO reference software dist10.tgz (ie at www.mp3-tech.org) Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Christopher Wise @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] RazorLame 1.1.0 released Dated: 01 Sep 00 01:12:21 [processed here: 05 Sep 00 14:12:48] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: mordor.ses.swin.edu.au 60ec01bf @REPLY: yucom.be 5dad805e @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01916 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:15:33 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id CAA28993 for mp3encoder-list; Fri, 1 Sep 2000 02:07:50 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from mordor.ses.swin.edu.au ([EMAIL PROTECTED] [136.186.9.27]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id CAA28990 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 02:07:46 +0200 @RFC-Received: from localhost (cwise@localhost) by mordor.ses.swin.edu.au (8.9.3/8.8.7) with ESMTP id KAA14276for [EMAIL PROTECTED]; Fri, 1 Sep 2000 10:12:21 +1100 @RFC-In-Reply-To: [EMAIL PROTECTED] @RFC-Message-ID: [EMAIL PROTECTED] @RFC-Sender: [EMAIL PROTECTED] From: Christopher Wise [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] On Thu, 31 Aug 2000, Roel VdB wrote: btw: why are mp3's shown anyway when I choose "encode"? I think only showing .wav by default would be better? No, please don't change this. RazorLame can can be used to set up re-encoding of mp3 files. This is very useful if you want to re-encode at a lower bitrate for a Rio. Thanks Holger for a great program. Now all I need is for lame to keep the ID3 tags when re-encoding. Has anyone implemented this yet? Chris Wise -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:15 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Estrunfus Maleficus @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: [MP3 ENCODER] linux lossless encoder Dated: 02 Sep 00 01:42:57 [processed here: 05 Sep 00 14:12:13] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: zxmail.com ec2de30a @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i586) @CHRS: LATIN-0 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01191 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:01:33 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id BAA32662 for mp3encoder-list; Sat, 2 Sep 2000 01:44:55 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from fep01-svc.mail.telepac.pt (fep01-svc.mail.telepac.pt [194.65.5.200]) by geek.rcc.se (8.8.4/8.7.3) with ESMTP id BAA32659 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 01:44:53 +0200 @RFC-Received: from zxmail.com ([212.55.160.40]) by fep01-svc.mail.telepac.pt (InterMail vM.4.01.02.27 201-229-119-110) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Sat, 2 Sep 2000 00:53:22 +0100 @RFC-Message-ID: [EMAIL PROTECTED] @RFC-X-Accept-Language: en @RFC-Sender: [EMAIL PROTECTED] From: Estrunfus Maleficus [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] hello , considering that there isn't a monkeys audio for linux, I don't supose there are any developers out there would like to take a look a shorten to see if it could be improved to match monkeys audio performance , or perhaps even better? :) well thats part of my wishlist any volunteers up to the chalenge P.S.: am I the only one that feels that development on grip as stagnated wa before time?, I never saw the promissed rip first, encode later function, any volunteers for that too? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:01 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Steve Lhomme @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] RazorLame 1.1.0 released Dated: 01 Sep 00 08:23:11 [processed here: 05 Sep 00 14:12:46] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: cybercable.fr 66bb3f2e @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: Microsoft Outlook Express 5.50.4133.2400 @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01895 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:15:14 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id IAA29550 for mp3encoder-list; Fri, 1 Sep 2000 08:24:28 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from camus.cybercable.fr (camus.cybercable.fr [212.198.0.200]) by geek.rcc.se (8.8.4/8.7.3) with SMTP id IAA29547 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 08:24:26 +0200 @RFC-Received: (qmail 8955820 invoked from network); 1 Sep 2000 06:28:40 - @RFC-Received: from r182m156.cybercable.tm.fr (HELO pc) ([195.132.182.156]) (envelope-sender [EMAIL PROTECTED]) by camus.cybercable.fr (qmail-ldap-1.03) with SMTP for [EMAIL PROTECTED]; 1 Sep 2000 06:28:40 - @RFC-Message-ID: 002101c013dd$b1dc9f60$[EMAIL PROTECTED] @RFC-References: [EMAIL PROTECTED] @RFC-X-Priority: 3 @RFC-X-MSMail-Priority: Normal @RFC-Sender: [EMAIL PROTECTED] From: "Steve Lhomme" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Yep, and I personnaly use a lame EXE with libnsdfile support, so not only wav files are supported ! - Original Message - From: "Christopher Wise" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, September 01, 2000 1:12 AM Subject: Re: [MP3 ENCODER] RazorLame 1.1.0 released On Thu, 31 Aug 2000, Roel VdB wrote: btw: why are mp3's shown anyway when I choose "encode"? I think only showing .wav by default would be better? No, please don't change this. RazorLame can can be used to set up re-encoding of mp3 files. This is very useful if you want to re-encode at a lower bitrate for a Rio. Thanks Holger for a great program. Now all I need is for lame to keep the ID3 tags when re-encoding. Has anyone implemented this yet? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:15 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Holger Dors @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re[2]: [MP3 ENCODER] RazorLame 1.1.0 released Dated: 01 Sep 00 12:49:32 [processed here: 05 Sep 00 14:12:41] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: kittelberger.de b2798894 @REPLY: uni-mb.si 7575c603 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: The Bat! (v1.45 S/MIME) @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01836 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:13:51 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id MAA31021 for mp3encoder-list; Fri, 1 Sep 2000 12:45:28 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from gallileo.kittelberger.net (gallileo.kittelberger.net [62.192.3.52]) by geek.rcc.se (8.8.4/8.7.3) with SMTP id MAA31018 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 12:45:25 +0200 @RFC-Received: (qmail 28793 invoked from network); 1 Sep 2000 10:50:43 - @RFC-Received: from ns.kittelberger.net (HELO seven.kittelberger.intra) (62.192.3.24) by gallileo.kittelberger.net with SMTP; 1 Sep 2000 10:50:43 - @RFC-X-Priority: 3 (Normal) @RFC-Message-ID: [EMAIL PROTECTED] @RFC-In-reply-To: [EMAIL PROTECTED] @RFC-References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @RFC-Sender: [EMAIL PROTECTED] From: Holger Dors [EMAIL PROTECTED] To: David Balazic [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Hello David, But I noticed that the -B option is not present in the command line ! congratulations, you found a bug! ;-) I'll fix this in the next release. ( according to the "Show LAME commands:" button , shouldn't that be "show used LAME options:" ? ) Indeed, I'll add this to my to do list. An idea for the layout : put the min and max VBR bitrate slider on the same screen ! Yes, I thought about that myself recently. Why is the ABR bitrate not a slider ? With the option of manual number entry maybe. I'm not sure if a slider is a good control for this; I use sliders for the bitrates because normally only a discreet set of values are available. Regards, Holger Dors mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:13 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Robert Hegemann @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re: [MP3 ENCODER] lame/CODING_STYLE Dated: 01 Sep 00 11:24:59 [processed here: 05 Sep 00 14:12:42] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: bob d7c10f8b @REPLY: fuchs.offl.uni-jena.de fe567c04 @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: KMail [version 1.0.29.2] @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01846 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:14:03 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id LAA30449 for mp3encoder-list; Fri, 1 Sep 2000 11:38:54 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by geek.rcc.se (8.8.4/8.7.3) with SMTP id LAA30445 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 11:38:47 +0200 @RFC-Received: (qmail 13202 invoked by uid 0); 1 Sep 2000 09:42:27 - @RFC-Received: from pec-66-32.tnt4.me.uunet.de (HELO bob) (149.225.66.32) by mail.gmx.net with SMTP; 1 Sep 2000 09:42:27 - @RFC-Content-Type: text/plain @RFC-References: [EMAIL PROTECTED] @RFC-In-Reply-To: [EMAIL PROTECTED] @RFC-MIME-Version: 1.0 @RFC-Message-Id: 00090111374302.00422@bob @RFC-Content-Transfer-Encoding: quoted-printable @RFC-Sender: [EMAIL PROTECTED] From: Robert Hegemann [EMAIL PROTECTED] To: [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Frank Klemm schrieb am Fre, 01 Sep 2000: lame/CODING_STYLE, version 0.001 ;-) - This is the first try of a Coding Style: notes on some points * Don't use tabulators (the character with the value '\t') in source code, especially these with a width of unequal 8. Lame sources are using different sizes for tabulators. I don't like tabulators too * Functions should be not longer than 50 lines of code. this is debateable Every function should only do ONE thing, and this should be done well. every proggi thinks his functions are doing well, until he finds out the flaws he introduced. * Document functions. programmers don't document, you know ;-) OK, your point is clear and I'll try to add more comments (hopefully useful remarks..) * Don't use single 'short' variables to save storage. Short variables are especially on Pentium Class Computer much slower than int's. DEC alpha also hates short variables. Example: float bla [1024]; short i; for ( i = 0; i 1024; i++ ) bla [i] = i; I'm not so sure about shorts. Documents on the Intel compiler suggest for example to put the index variables of nested loops in a struct to improve cache performance, this way they would be in the same cache line. Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:14 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Message *bounced*
*** WARNING -- WARNING -- WARNING -- WARNING -- WARNING -- WARNING *** * * The e-mail-message appended below is list- or mailserver-related * * That type of mail will by definition not be processed on this system * and in general is not accepted in the fidonet.org-domain. * * To avoid these bouncings the listkeeper is kindly requested to * remove any subscription coming from a z2.fidonet.org-style address. * *If you have reason to believe your message was removed without due * reason then kindly inform '[EMAIL PROTECTED]'. * From: Holger Dors @2:292/862 To:Sergey Sapelin @2:5020/1844.33 Subj.: Re[4]: [MP3 ENCODER] RazorLame 1.1.0 released Dated: 01 Sep 00 13:01:09 [processed here: 05 Sep 00 14:12:42] @TOPT 33 @INTL 2:5020/1844 2:292/862 @MSGID: kittelberger.de af39c136 @REPLY: yucom.be a7b25a3b @REPLYADDR: [EMAIL PROTECTED] @REPLYTO: 2:292/862@fidonet UUCP @PID: The Bat! (v1.45 S/MIME) @CHRS: LATIN-1 2 @RFC-Received: from geek.rcc.se ([EMAIL PROTECTED] [193.15.234.212]) by infomag.iguana.be (8.9.3/8.9.3) with ESMTP id CAA01840 for [EMAIL PROTECTED]; Sat, 2 Sep 2000 02:13:56 +0200 @RFC-Received: (from majordom@localhost) by geek.rcc.se (8.8.4/8.7.3) id MAA31076 for mp3encoder-list; Fri, 1 Sep 2000 12:57:07 +0200 @RFC-X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f @RFC-Received: from gallileo.kittelberger.net (gallileo.kittelberger.net [62.192.3.52]) by geek.rcc.se (8.8.4/8.7.3) with SMTP id MAA31073 for [EMAIL PROTECTED]; Fri, 1 Sep 2000 12:57:03 +0200 @RFC-Received: (qmail 231 invoked from network); 1 Sep 2000 11:02:21 - @RFC-Received: from ns.kittelberger.net (HELO seven.kittelberger.intra) (62.192.3.24) by gallileo.kittelberger.net with SMTP; 1 Sep 2000 11:02:21 - @RFC-X-Priority: 3 (Normal) @RFC-Message-ID: [EMAIL PROTECTED] @RFC-In-reply-To: [EMAIL PROTECTED] @RFC-References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] @RFC-Sender: [EMAIL PROTECTED] From: Holger Dors [EMAIL PROTECTED] To: Roel VdB [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] Hello Roel, 30 options in 1 screen are less complicated than 30 options scattered over 5 screens. This can probably be disputed for very long! - 1 screen (oversight clarity) - in top, a (greyed out or so) continuous display of current command line. I never understood why enabling this is an option. - only a limited set of "core" options. stereo mode, bitrate, encoder mode, delete after, and the most common flags. Just so you have a nice oversight of options. - a box to add non-common command line options. - a flag to make lame only use that box, instead of adding the content to current selected options. The problem starts with the "most common flags". Who will define those? You've left out VBR, for a start. Similar, I know at least one person who was very happy about that the "Audio Processing" tab where you can set sampling frequency and filter options. Personally, I started RL because of the many options Lame has to offer, it's fun to play with them, and I wanted an easy interface. I admit that the options dialog is far from being perfect, but I think it's a good start. then, why no multithread? it'd be nice to update the to-be-encoded list in one window while the encoding-box is somewhere else... Actually, this is on my wish list. However, unlike LAME, I'm currently the only programmer in RazorLame (I hope this changes soon!), and the wishlist grows and grows. Additional, I do this in my spare time, so please be patient. Regards, Holger Dors mailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) @Via ifmail 2:292/862@fidonet, Sat Sep 2 2000 at 02:14 (2.14-tx8.10) @Via D'Bridge 1.58 2:292/854 09/05 14:04 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi Pass MP3 Encoder
Frank Klemm ([EMAIL PROTECTED]) wrote: 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. This has the obvious disadvantage of not being possible when reading from a pipeline. But as a user I would definitely use this option if it were offered. -- Greg Wooledge| "Truth belongs to everybody." [EMAIL PROTECTED] | Red Hot Chili Peppers http://www.kellnet.com/wooledge/ | PGP signature
[MP3 ENCODER] New Decoder For Winamp
Hi folks, Have you already seen this from Justin of Nullsoft ??? http://landoleet.org/~deadbeef/in_mp3_260_alpha7.zip It is linked from http://www.fileclicks.com front page, just scroll down until Today's Top News Clicks section. Here what is says: "New Decoder Plug-in For Winamp: The new decoder plug-in for Winamp is coming along good, download the alpha version 7 above. It's not quite as fast as Nitrane, but is completely ISO compliant. Justin says "there's plenty of room for improvement". A few changes : bugfix: vbr headers read when id3v2 tag is present now, downsampling modes have better vis support, id3v2 writing support, stream info box and more." Greetings, -E. [EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
