Re: [MP3 ENCODER] min bitrate and bit reservoir (was: MS switching)
There are two possiblities for display update frequency: 1st) #define I_HAVE_NEVER_SEEN_LAME_ON_A_486_100_OR_A_ATHLON_1000 and display updates every 50 frames (MPEG-1) or 100 frames (MPEG-2) (Why this differences?) This difference is probably because in mpeg-1 there are 2 granules in a frame and in mpeg-2 there is only one. This also prevents lame from update frequencies in the range of 50...60 Hz (resulting in additional hum!) on Athlon 1000 systems coding mono, low quality MPEG-2 files. Sounds worse. Are you saying (I hope say is correct) that on fast systems, Lame display changes the result of the mp3? If this is the case, I think that we MUST find why. Otherwise note, that the old behave updates display every 4.5 minutes (386/40 with Cyrix copro, 8 years old) or 8.5 hours (386SX/16 without copro, 10 years old). off topic: is there anyone on this planet encoding mp3 with a 386? The slowest thing I personnaly used for mp3 encoding was dx4-100, and it was really awfull. Another question: What is ETA? A basque terror organization? I don't found it in any printed dictionary, also not in the big webster I bought in England. But you find nearly all C keywords in it ;-) There are 2 indications of the remaining time in Lame: one for the remaining time for the Lame process, and the other for the overall system remaining time. Tthey could be different if you're using a lot of simultaneous tasks on your computer. But I don't remember which one is which one, and I'm not sure if it works on every OS. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Percentages (informational)
May be too difficult for end users, but nice for development. I don't think that it may be annoying for end users. Another question would be, what is best: * Showing the percentage relative to the number of already coded frames I would personnaly vote for this one. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] min bitrate and bit reservoir (was: MS switching)
Jaroslav Lukesh wrote: | Another question: | What is ETA? A basque terror organization? I don't found it in any printed | dictionary, also not in the big webster I bought in England. But you find | nearly all C keywords in it ;-) | | | eta: the 7th letter of the Greek alphabet -- H or n | ' | Eta: basque terror organization in spain E-stimated T-ime A-bout it mean which time you should will go away from computer, but not so exactly, only estimated. I also recall Elapsed Time Available. Dunno what exatly it means... IMHO ETA in general means how much you have to wait until something happens. | The other one is translating american billions (10^9) and trillions | (10^12) to Billionen (10^12) and Trillionen (10^18). You got fantastic | gross national product for the U.S.A. with values in the range of 10^10 | US $ per citicen. Not only in germany, but in Czech too :) But it's the americans fault ! :-) For using those non-standard units ! David Balazic -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] min bitrate and bit reservoir (was: MS switching)
Frank Klemm wrote: On Tue, Sep 12, 2000 at 12:25:46PM +0200, Gabriel Bouvigne wrote: FhG forces 48 kHz on 320 kbps. Maybe to bring the bits/granule ratio to the right place. But in VBR mixed sampling rates are fordidden. Also in CBR. I recall seeing a test bitstream with changing sample-rate. But I could be wrong. David Balazic -- "Be excellent to each other." - Bill Ted -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --voice
Thanks - I'll revisit your website. Another question :) Is there a preferred (or even mandatory) sequence to command-line opions for Lame ? I remember how quirky DOS could be in this respect The only problem is if you use incompatiable options - LAME does not check for this. Examples would be -h and -f together, or -k and --lowpass together. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] --voice
Mark Taylor schrieb am Mit, 13 Sep 2000: Thanks - I'll revisit your website. Another question :) Is there a preferred (or even mandatory) sequence to command-line opions for Lame ? I remember how quirky DOS could be in this respect The only problem is if you use incompatiable options - LAME does not check for this. Examples would be -h and -f together, or -k and --lowpass together. Mark As a general rule, the last given option overrides the previous: -f -h = -h would be used, same goes if you want to override a few preset settings. So I don't see a problem, but a feature ;-) Ciao Robert -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] RPC support
On 12 Sep 2000, Frank Klemm wrote: RPC support, SMP support and distributed computing would be a very nice thing for LAME and would be an outstanding feature. Are there are plans and interests to support this? Not this year, but starting with this things in spring next year, not earlier. The core of lame is less or not effected, but the outer layers of lame. I don't think this is needed. Most people don't just encode one file but 1-99. It's trivial to parallelize (sp?) this, my frontend (jack.sourceforge.net) does it for one machine (SMP) and I know there are solutions for a distributed network. IMHO it's not worth the risks and effort to put this into lame. cu arne -- Arne Zellentin [EMAIL PROTECTED] -- I tend to agree. This has been discused before, and there were only a few contrived examples where SMP make sense. Also, I think the core of LAME would be effected. Because of frame dependencies, the parallelization almost has to be at lowest level. If you really need this, I would suggest buying a C compiler (like www.pgroup.com) which supports openMP style automatic loop-level parallelism. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] min bitrate and bit reservoir (was: MS switching)
Frank, your are missing a third option: PROJECT_MAINTAINER_DOES_NOT_CARE_AND DOES_NOT_WANT_THIS_CODE_IN_LAME The display is updated every 50 frames. It is simple and works well enough. I want this type of code kept to an absolute minimum since this kind of stuff really belongs in the front end. Most GUIs which use LAME already do their own status display. I dont want to see even more timing code in lame.c. Mark X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f Received: (from pfk@localhost) by fuchs.offl.uni-jena.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id UAA04980 for [EMAIL PROTECTED]; Tue, 12 Sep 2000 20:14:41 +0200 Date: Tue, 12 Sep 2000 20:14:41 +0200 From: Frank Klemm [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Sender: [EMAIL PROTECTED] Precedence: bulk Reply-To: [EMAIL PROTECTED] There are two possiblities for display update frequency: 1st) #define I_HAVE_NEVER_SEEN_LAME_ON_A_486_100_OR_A_ATHLON_1000 and display updates every 50 frames (MPEG-1) or 100 frames (MPEG-2) (Why this differences?) 2nd) Do not define I_HAVE_NEVER_SEEN_LAME_ON_A_486_100_OR_A_ATHLON_1000 You can also define MY_PREFERED_UPDATE_STEP by values like 1, 2, 5, 10, 20, 50, 100 (default is 1). Update interval is 2 seconds (if not modified by -disptime xxx) time + needed for display (so no lockup is possible), additional frame number steps can be rounded to multiples of MY_PREFERED_UPDATE_STEP. But the display will not more often than every 2 seconds updated (if not modified by -disptime xxx). The standard value of 2 seconds is also debatable. It's a float, so personal preferences can be satisfied very accurately ;-) This also prevents lame from update frequencies in the range of 50...60 Hz (resulting in additional hum!) on Athlon 1000 systems coding mono, low quality MPEG-2 files. Sounds worse. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] More Frame Analyzer Questions
I'm monitoring the encoding of material originally recorded in the 30's (now on CD). When I look at the MDCT and scale band info: Left and Mid Channels closely match. Right Channel shows very little energy. Side Channel shows very little energy. In CoolEdit LR "appear" to be almost identical(mono). Given the age of the recording and Lukesh's post about "pseudo stereo" processing I thought that Left and Right would have matched closely in the frame analyzer. What am I missing or misunderstanding? You say the MDCT *and* scale band info have problems. So I'm assuming the L,R,M S channel PCM data looks ok? Otherwise what you are seeing is expected - because of a flaw in the frame analyzer. The scaleband info (psycho acoustic data) is only plotted for the mode which was actually used. So if the frame is encoded mid/side, then the M data is plotted when you select L channel (and the S data is plotted for the R channel). If the frame is encoded in regular stereo, then only L and R psycho acoustic data is plotted, even if you display the M or S PCM channels. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] min bitrate and bit reservoir (was: MS switching)
:: :: Frank, your are missing a third option: :: :: PROJECT_MAINTAINER_DOES_NOT_CARE_AND DOES_NOT_WANT_THIS_CODE_IN_LAME :: :: The display is updated every 50 frames. It is simple :: and works well enough. :: :: I want this type of code kept to an absolute minimum since this kind :: of stuff really belongs in the front end. Most GUIs which use LAME :: already do their own status display. I dont want to see even more :: timing code in lame.c. :: Then move it to a separate function and a separate file. Then you don't pollute the coder functionality with things like that. An functions become shorter. Programmers may like large functions, at least maintainers not. -- 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] min bitrate and bit reservoir (was: MS switching)
:: :: This also prevents lame from update frequencies in the range of :: 50...60 Hz :: (resulting in additional hum!) on Athlon 1000 systems coding mono, :: low :: quality MPEG-2 files. Sounds worse. :: :: Are you saying (I hope say is correct) that on fast systems, Lame display :: changes the result of the mp3? If this is the case, I think that we MUST :: find why. :: Not the result of the MP3, but when listening to FM radio you can hear what the computer makes. Especially on non closed computers. Especially the video card seems to generate lots of noise when blittering images. :: Otherwise note, that the old behave updates display every 4.5 minutes :: (386/40 with Cyrix copro, 8 years old) or 8.5 hours (386SX/16 without :: copro, 10 years old). :: :: off topic: is there anyone on this planet encoding mp3 with a 386? The :: slowest thing I personnaly used for mp3 encoding was dx4-100, and it was :: really awfull. :: Yes, me. I measured the time to generate one frame. These are two slow firewall computers. The 386SX/16 has 8 MB of RAM, the 386DX/40 16 MB. Lame works on it. :: Another question: :: What is ETA? A basque terror organization? I don't found it in any printed :: dictionary, also not in the big webster I bought in England. But you find :: nearly all C keywords in it ;-) :: :: There are 2 indications of the remaining time in Lame: one for the remaining :: time for the Lame process, and the other for the overall system remaining :: time. Tthey could be different if you're using a lot of simultaneous tasks :: on your computer. But I don't remember which one is which one, and I'm not :: sure if it works on every OS. :: The CPU time display shows it in CPU time, i.e. in real CPU clocks. The REAL time display shows the REAL world time which normal humans really interest. The last is the remaining real world time until the program is finished. -- 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] Percentages (informational)
[Charset iso-8859-2 unsupported, filtering to ASCII...] :: Frank Klemm wrote: :: :: The following outputs have the following meanings: :: ::[ ] p = 0.00%, never used ::[%..] 0.00% p 0.01% ::[%.0] 0.01% p 0.05% ::[%.1] 0.05% = p 0.15% ::[%.2] 0.15% = p 0.25% :: ... ::[%.9] 0.85% = p 0.95% ::[ 1%] 0.95% = p 1.5% ::[ 2%] 1.5% = p 2.5% ::[ 3%] 2.5% = p 3.5% :: ... ::[99%] 98.5% = p 99.5% :: [100%] 99.5% = p +oo :: :: Why not just allocate more characters , like [0.13%] ? :: That's also possible. -- 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/ )
