Re: [MP3 ENCODER] SHOUTcast streamer plugin for Macintosh using LAME
If anyone interested in checking out what LAME is capable of, check out realtime SHOUTcast broadcast plugin for AMP Radio. you could have made one for icecast instead :) jack. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Normalize audio input
About the normalizing: The link was wrong. It should be this one: http://www.audiograbber.com/normalize.html Audiograbber has some advanced settings for normalization, but I have yet to find a program to use a sliding scale (equivalent to your father controlling the volume button, ensuring the volume is always about the same level). Gerben ([EMAIL PROTECTED]) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame-3.83beta
Mark Taylor wrote: The problem is gfc-cw_lower_index. It is set to 6, and is never changed. Yet it has been changed to -1001465578, so there is some kind of buffer overflow (which could be anywhere :-( trashing gfc-cw_lower. Weird stuff. I can't reproduce this problem on my PowerMac (compiler is Metrowerks CW Pro 5). Maybe Kimmo and Sigbjørn could tell which compiler they use. Best regards, Wilfried Behne -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[2]: [MP3 ENCODER] Normalize audio input
Hello Gabriel, Saturday, May 27, 2000, 2:44:36 PM, you wrote: GB Good point here. If I'm not too wrong, a kind of normalization can be done GB by just changing the scalefactor value. In this case, such an option would not change the GB encoding process. Lame could encode each frame as usual, but could change GB this value during the frame packaging. I think this should not interfere GB much with the main goal of Lame, wich is mp3 encoding. This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN ratio over the range of quant values. I don't understand why you would raise a input level by 3/4th, encode and raise to 4/3th whilst decoding, but I take there was a reason for this, and maybe this is not something to tinker with? -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] lame-3.83beta: cw_lower_index problem on PPC
On Sat, 27 May 2000, Mark Taylor wrote:
The problem is gfc-cw_lower_index. It is set to 6, and is never
changed. Yet it has been changed to -1001465578, so there is
I would start by putting print statements in lame_encode_frame(),
and see if you can narrow down in which major block
of code cw_lower_limit is overwritten (psycho acoustics, MDCTs,
outer_loop or format_bitstream?
The value is changed during L3psycho_anal in psymodel.c. I put lots of
assertions in the channel loop (a very long loop really!) and the value
was changed before the end of the loop:
---8---
assert(gfc-cw_lower_index == 6); /* line 865 */
/* threshold calculation for short blocks */
for (sblock = 0; sblock 3; sblock++) {
j = 0;
for (b = 0; b gfc-npart_s_orig; b++) {
int i;
FLOAT ecb;
ecb = gfc-energy_s[sblock][j++];
for (i = gfc-numlines_s[b]; i 0; i--) {
ecb += gfc-energy_s[sblock][j++];
}
eb[b] = ecb;
}
for (b = 0; b gfc-npart_s; b++) {
FLOAT8 ecb;
ecb = 0;
for (k = gfc-s3ind_s[b][0]; k = gfc-s3ind_s[b][1]; k++) {
ecb += gfc-s3_s[b][k] * eb[k];
}
thr[b] = Max(1e-6, ecb);
}
for (sb = 0; sb SBPSY_s; sb++) {
FLOAT8 enn, thmm;
enn = gfc-w1_s[sb] * eb[gfc-bu_s[sb]] + gfc-w2_s[sb] *
eb[gfc-bo_s[sb]];
thmm = gfc-w1_s[sb] *thr[gfc-bu_s[sb]] + gfc-w2_s[sb] *
thr[gfc-bo_s[sb]];
for (b = gfc-bu_s[sb]+1; b gfc-bo_s[sb]; b++) {
enn += eb[b];
thmm += thr[b];
}
/*
printf("gfc-cw_lower_index = 0x%08x\n", gfc-cw_lower_index);
printf("gfc-en[chn].s[sb][sblock] = 0x%08x\n",
gfc-en[chn].s[sb][sblock]);
printf("gfc-thm[chn].s[sb][sblock] = 0x%08x\n",
gfc-thm[chn].s[sb][sblock]);
*/
gfc-en[chn].s[sb][sblock] = enn;
gfc-thm[chn].s[sb][sblock] = thmm;
}
#if 0 /* line 905 */
assert(gfc-cw_lower_index == 6);
#endif
}
assert(gfc-cw_lower_index == 6); /* line 909 */
} /* end loop over chn */
assert(gfc-cw_lower_index == 6);
---8---
The result:
Assertion (gfc-cw_lower_index == 6) failed in file psymodel.c at line 909
On line 865 the assert condition is still true.
Note that the line numbers in my version are very different from the
original version, because I have lots of assertions added before these
ones.
But if I change the #if on line 905 to #if 1, the problem disappears and
lame seems to work ok. So it's quite difficult to track it down more
precisely. But I expect that it could be those gfc-en or gfc-thm that
could be accessed out of bounds.
Adding char dummy[1000]; to util.h before the variable cw_lower_index also
removes the problem. I could continue trying to use smaller values like
dummy[4] or dummy[8] to find out how much of the information is
overwritten and try to change the order or the variables in the structure
to find out which one causes the problem.
Someone who knows about this function could look into this more carefully
and maybe insert some assertions to check the bounds... oh, I might try to
use bounds-checking version of gcc to compile this on Alpha... too bad,
that I don't have (and there probably isn't available) a bounds-checking
version of gcc for AmigaOS and PPC. Has anyone else tried to compile and
run lame using bounds-checking?
Or then it could be of course something else. Once I really had a big
problem debugging a software. In the debugger, it worked it I
single-stepped the routine to a certain point but it failed if I
single-stepped one step less. And the code was fine and finally I managed
to track down a processor bug on 68060 (too bad that it was already a
documented one, i.e. a "feature"). :( It behaved the similar way,
disappeared when the order of instructions was changed. I don't have any
debugging tool for PPC and if I had, I had to learn first how to use that
anyway... :)
But I guess that in this case, this is just a bug in the software. The
function is very long, a way too long in my opinion, and because it wasn't
well indented, I had a little difficulties trying to find the end of that
channel for loop. Would it be a nice idea to break it into smaller
functions? Or does it make it that much slower? Compilers should be able
to inline those parts anyway...?
Kimmo
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] Normalize audio input
This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN ratio over the range of quant values. It would be easier to try answering your question after looking at this doc, but it seems that I don't have it. Is it possible for you to send it to me? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame-3.83beta
On Sun, 28 May 2000, Wilfried Behne wrote: The problem is gfc-cw_lower_index. It is set to 6, and is never changed. Yet it has been changed to -1001465578, so there is Weird stuff. I can't reproduce this problem on my PowerMac (compiler is Metrowerks CW Pro 5). Maybe Kimmo and Sigbjørn could tell which compiler they use. This occurs using SAS/C compiler but compiling with GCC doesn't work any better. I haven't checked if it crashes exactly for the same reason, but it seems that way. I'll try to use bounds-checking on Alpha and let you know if that complains about something. Kimmo -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lameusagethingy
Hello , latest usage says: " --freeformat LAME will produce a fixed bitrate, free format bitstream. User must specify the desired bitrate in kbs, which can be any integer between 8 and 320. Not supported by many decoders. " Shouldn't this be between 8 and 440? Why 440 or 320? According to the ISO doc, it does not seems that there is any upper limit to the bitrate. (The only limit is perhaps that it seems that only Xing based decoders and a few mpg123 based are able to decode it) Btw, did anyone tryed freeformat on Xaudio or Mad? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re[4]: [MP3 ENCODER] Normalize audio input
Hello Gabriel, Sunday, May 28, 2000, 12:09:47 PM, you wrote: This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN GB ratio over the range of quant values. GB It would be easier to try answering your question after looking at this doc, GB but it seems that I don't have it. Is it possible for you to send it to me? There's not much in to be honest, just a quick intro to audio compression. I'll look up the url: you can find one doc here: http://www.bok.net/~pan/ and the one I quoted: (don't remember where I found the .pdf, so I put it up my page (temp)): http://users.belgacom.net/gc247244/extra/Digital_Audio_Compression_01oct1993DTJA03P8.pdf (only about 85kbytes) -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] SHOUTcast streamer plugin for Macintosh using LAME
Greetings all, If anyone interested in checking out what LAME is capable of, check out realtime SHOUTcast broadcast plugin for AMP Radio. Or indeed - try using it with Liveice / LiveiceXMMS where LAME is now the default encoder. myplay even has 3 test streams which run 24 horus a day at http://abv-icy1.myplay.com:8000 http://abv-icy1.myplay.com:8010 http://abv-icy1.myplay.com:8020 Still it's good to see one for the Mac - I hope you've gone and made it icecast compatible Scott Manley (aka Szyzyg) /-- _@/ Mail -\ ___ _ _ __ __ _ | Armagh Observatory | / __| __ ___| |_| |_ | \/ |__ _ _ _ | |___ _ _ | Armagh | \__ \/ _/ _ \ _| _| | |\/| / _` | ' \| / -_) || | | Northern Ireland | |___/\__\___/\__|\__| |_| |_\__,_|_||_|_\___|\_, | | BT61 9DG. | http://star.arm.ac.uk/~spm/welcome.html |__/ \=/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Re[2]: [MP3 ENCODER] Normalize audio input
- Original Message - From: Roel VdB [EMAIL PROTECTED] To: Gabriel Bouvigne [EMAIL PROTECTED] Sent: Sunday, May 28, 2000 4:06 AM Subject: Re[2]: [MP3 ENCODER] Normalize audio input Hello Gabriel, Saturday, May 27, 2000, 2:44:36 PM, you wrote: GB Good point here. If I'm not too wrong, a kind of normalization can be done GB by just changing the scalefactor value. In this case, such an option would not change the GB encoding process. Lame could encode each frame as usual, but could change GB this value during the frame packaging. I think this should not interfere GB much with the main goal of Lame, wich is mp3 encoding. This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN ratio over the range of quant values. I don't understand why you would raise a input level by 3/4th, encode and raise to 4/3th whilst decoding, but I take there was a reason for this, and maybe this is not something to tinker with? I don't really understand the real utility of this 3/4 power. If someone knows about it, please drop us a line. About this normalization thing, here is a quote from Mark some times ago: "One easy thing would be to change the value of global_gain. it's an 8bit int stored for each channel of each granule. Changing this +/-1 changes the volume by .75db." It's the thing that I think could be used, without affecting the encoding process. Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame3.84 (CVS) in pipelines b0rken since 23.May
From: "Takehiro Tominaga" [EMAIL PROTECTED] "M" == Mathew Hendry [EMAIL PROTECTED] writes: M I got Takehiro's code working (the fp stack was out of order) M but it seems to be slightly slower than the original. Here's M the fixed code anyway - the main loop in quantize_xrpow slow umm What kind of architechture you use ? Sorry, should have mentioned I'm using a Celery 400 / Win2k. The difference in speed is small but consistent. if P6 (dynamic execution arch.), it stalls continuous fmul section. if P5 or K6-2/III, it can't speed up by fxch pipeline hack. Maybe Acy Stapp can help out here. His original MSVC code was aimed at P6, but I think he made some comments about changes for P5 when he posted the patch. My gcc code was a conversion of that. Anyway, I am now replacing these asm routines into GOGO's more aggressive code. 3DNow!/SSE will bring us a crazyly fast encoding. Bah, and I don't have either of those extensions... still waiting for decent dual K7 boards to appear. ;) -- Mat. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Normalize audio input
At 09:24 28/05/00 +0200, you wrote: Normalization consists of determining the output leven of the audio data, and then multiplying the audiodata with a certain factor so that the highest value becomes 95 or 99% of the absolute maximum (plus or minus 32768). The trick is twofold: First of all, determining the output level is not that obvious. Many programs just count the highest peak in the data, but one peak can thus influence the rest of the data considerably. Other programs calculate the maximum and the desired level with more sophisticated algorithms (root mean squared, which aproaches the human hearing better than a peak scan) You could consider an adaptive algorithm, which would divide the data in blocks, determine the highest peak in each block, and would then use a gradually sliding factor to multiply the samples with. Hello, Yes, but if you use RMS you must need compression to avoid clips, and compression means a reduction in the dynamic range, and less dynamic range reduces the "quality" but it sounds stronger. Recent CDs are RMS normalized (Usually around -8 db) and they sound really horrible (IMO). I think that MP3 coding for a -8 db RMSed song need more bits and is more difficult to detected masked freqs. Am I wrong ? I think that kind of normalization should be done in the decompression process (it means information destruction) like a radio station compressor does. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] FYI: mp3licensing
it seems FhG and Thomson changed their patent policy. see http://www.mp3licensing.com/index.html --- Takehiro TOMINAGA // may the source be with you! -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] FYI: mp3licensing
Hello Takehiro, Sunday, May 28, 2000, 7:05:46 PM, you wrote: TT it seems FhG and Thomson changed their patent policy. TT see http://www.mp3licensing.com/index.html thanks :) quotes: Hello Roel, Sunday, May 28, 2000, 8:26:01 PM, you wrote: RV Hello Takehiro, RV Sunday, May 28, 2000, 7:05:46 PM, you wrote: TT it seems FhG and Thomson changed their patent policy. TT see http://www.mp3licensing.com/index.html thanks :) quotes: RV mp3 Software Decoders/Players distributed free-of-charge via the RV Internet for personal use of end-users: RV No license fee is expected for desktop software mp3 decoders/players that are distributed free-of-charge via the Internet for personal use of end-users. RV mp3 Software Encoders (patents-only): RV If you have developed your own implementation of an mp3 encoder or if you have licensed such an implementation from a third party, you need a patent-only license. RV US$ 2.50 per unit RV US$ 15,000 annual minimum, payable upon signature and each following year in January, fully creditable against annual sales. RV $15.000 a year minimum. RV Limited Demo mp3 Software Encoders RV In general, our licensing model for software mp3 encoder products is based on per-unit royalties. The license agreement includes the right to distribute limited demo mp3 encoders free-of-charge RV to end-users for the sole purpose of generating sales of upgrades to full mp3 encoders, bearing a per-unit royalty as mentioned above. RV The patent royalties for the right to distribute such limited demo mp3 encoders are (In case you wish to use the Fraunhofer IIS mp3 encoder, the numbers double): RV Limited to either 20 encodes or 30 days RV No additional payment RV Limited to 56 kpbs, 24 kHz, mono/stereo RV One-time payment of US$ 100,000 RV Limited to 96 kpbs, all sample rates, mono/stereo RV One-time payment of US$ 1,000,000 So if you want to distribute a demo, you need to pay $100??? ha! RV Royalty Summary RV mp3 Decoders/Players/Decoder ICs RV US$ 0.50 per unit (patents-only) RV Paid-up licenses for Windows/MacOS software decoders RV Software mp3 Encoders RV US$ 2.50 per unit (patents-only); or RV US$ 5.00 per unit (patents and object code developed by Fraunhofer IIS-A). RV Hardware mp3 Encoders RV US$ 2.50 per unit (patents-only) RV Electronic Music Distribution RV 1.0 % of revenue; minimum US$ 0.01 per download (pay-audio, music-on-demand, internet-radio and other types of selling mp3 files). RV Minimum Royalties RV All agreements with running royalties have an annual minimum of US$ 15,000, creditable against annual royalties. -- Best regards, Roelmailto:[EMAIL PROTECTED] -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] SHOUTcast streamer plugin for Macintosh usingLAME
Greetings all, If anyone interested in checking out what LAME is capable of, check out realtime SHOUTcast broadcast plugin for AMP Radio. Or indeed - try using it with Liveice / LiveiceXMMS where LAME is now the default encoder. myplay even has 3 test streams which run 24 horus a day at http://abv-icy1.myplay.com:8000 http://abv-icy1.myplay.com:8010 http://abv-icy1.myplay.com:8020 Still it's good to see one for the Mac - I hope you've gone and made it icecast compatible One thing that'd be cool if somebody put into LAME is a good exciter with adjustable lpf. so that there isnt as much aliasing in low bitrate streams. I guess that just remains as a wishlist =) Dmitry -- Dmitry Boldyrev Subband Software, Inc. http://www.subband.com -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Normalize audio input
Hello Gabriel, Saturday, May 27, 2000, 2:44:36 PM, you wrote: GB Good point here. If I'm not too wrong, a kind of normalization can be done GB by just changing the scalefactor value. In this case, such an option would not change the GB encoding process. Lame could encode each frame as usual, but could change GB this value during the frame packaging. I think this should not interfere GB much with the main goal of Lame, wich is mp3 encoding. This "scalefactor", would this touch the "non uniform quantization" as described in the Davis Yen Pan doc? free quote: LIII raises input to 3/4th power to get more consistent SN ratio over the range of quant values. I don't understand why you would raise a input level by 3/4th, encode and raise to 4/3th whilst decoding, but I take there was a reason for this, and maybe this is not something to tinker with? I don't really understand the real utility of this 3/4 power. If someone knows about it, please drop us a line. I dont really know either, but I think it is to normalize the MDCT coefficients. For music, the amplitudes of these coefficients drop off sharply as the frequency is increased. Rasing them all to the 3/4 power before quantization has the effect of allocating more bits to the smaller coefficients. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] SHOUTcast streamer plugin for Macintosh using LAME
One thing that'd be cool if somebody put into LAME is a good exciter with adjustable lpf. so that there isnt as much aliasing in low bitrate streams. I guess that just remains as a wishlist =) Sounds fun - how about somoen tells me how to fit such a thing into liveice ;-) There's already a compressor in there Scott Manley (aka Szyzyg) /-- _@/ Mail -\ ___ _ _ __ __ _ | Armagh Observatory | / __| __ ___| |_| |_ | \/ |__ _ _ _ | |___ _ _ | Armagh | \__ \/ _/ _ \ _| _| | |\/| / _` | ' \| / -_) || | | Northern Ireland | |___/\__\___/\__|\__| |_| |_\__,_|_||_|_\___|\_, | | BT61 9DG. | http://star.arm.ac.uk/~spm/welcome.html |__/ \=/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Normalize audio input
I just want to know how can I normalize, and I didn't ask how about expand LAME to support normalization. But wouldn't a lame-integrated normalization (i.e. scaling of the sample values) improve quality over a seperately done normalization, because the intermediate results would be floating-point instead of 16bit (or lesser) integer? I think that a simple scaling option in lame would be useful (i.e. something like --pre-scale scalefactor). As an alternative, are there any sound formats that use floating-point values for samples? If so, maybe lame could be made to be able to read such a format. If not, it should be quite trivial to include a raw floating-point format for use by custom-written preprocessing tools. Or am I just too paranoid about normalizing to 16bit integer values? -- Niklas I also worry about this, but usually there are much bigger problems to worry about :-) Right now, the resampling and the stereo-mono averaging in LAME is done with short ints because the encoding routines want short int's for the input. This does result in some loss of precision, so it might be worth trying to convert "mfbuf" from short int to float. If the speed impact is negligible, I think all internal processing should be done in floating point. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lameusagethingy
Gabriel Bouvigne schrieb am Son, 28 Mai 2000: Hello , latest usage says: " --freeformat LAME will produce a fixed bitrate, free format bitstream. User must specify the desired bitrate in kbs, which can be any integer between 8 and 320. Not supported by many decoders. " Shouldn't this be between 8 and 440? Why 440 or 320? According to the ISO doc, it does not seems that there is any upper limit to the bitrate. (The only limit is perhaps that it seems that only Xing based decoders and a few mpg123 based are able to decode it) Btw, did anyone tryed freeformat on Xaudio or Mad? Regards, -- Gabriel Bouvigne - France [EMAIL PROTECTED] icq: 12138873 MP3' Tech: www.mp3-tech.org Another decoder for freeformat streams is l3dec from FhG. Version 2.72 has an -ff switch to search for free formats. If you are interested to see what lame puts into the ancillary data section, you can write it out into a seperate file too. usage:l3dec bitstream [output] -switches switches: -h display this help message -fb xxxbegin decoding with frame xxx -fn xxxdecode xxx frames -sasearch again after loss of synchronization -ffsearch for free format bitstream -snd write file with SND-Header -wav write file with WAV-Header -aif write file with AIFF-Header -aic write file with AIFC-Header -h24 write hex 24bit output -ign ignore error messages -sti read input from stdin -sto write output to stdout -a xxx write ancillary data in file xxx -aba ancillary data is byte aligned -afh ancillary data in FhG mode With 320 kbits free format streams l3dec is at its limits: # Now decoding layer III, 44.1 kHz, free ca. 320 kbit/s, stereo # frame no: 130 # # ERROR (300c): Granule exceeds maximum dynamic part length Robert -- e-mail: [EMAIL PROTECTED] homepage: http://linux.unixcity.de/catwalk/index.html -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lameusagethingy
Another decoder for freeformat streams is l3dec from FhG. Version 2.72 has an -ff switch to search for free formats. If you are interested to see what lame puts into the ancillary data section, you can write it out into a seperate file too. usage:l3dec bitstream [output] -switches switches: -h display this help message -fb xxxbegin decoding with frame xxx -fn xxxdecode xxx frames -sasearch again after loss of synchronization -ffsearch for free format bitstream -snd write file with SND-Header -wav write file with WAV-Header -aif write file with AIFF-Header -aic write file with AIFC-Header -h24 write hex 24bit output -ign ignore error messages -sti read input from stdin -sto write output to stdout -a xxx write ancillary data in file xxx -aba ancillary data is byte aligned -afh ancillary data in FhG mode With 320 kbits free format streams l3dec is at its limits: # Now decoding layer III, 44.1 kHz, free ca. 320 kbit/s, stereo # frame no: 130 # # ERROR (300c): Granule exceeds maximum dynamic part length I get this message trying to play back 320kbs CBR streams too, with or without "--strictly-enforce-ISO". So I think it just chokes at 320kbs in general. It had no problem handling 310kbs free format. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] The coder
Gentlemen, I must thank you for the recent improvements to LAME (not to mention the removal of dependence on ISO source code). We are currently compiling a "20 year" celebration for the independent classical record label Hyperion Records and, to make it easy for the compiler to get the tracks in a good order, I have encoded all the pieces she needs into 128kbit/s files which she can play on her (Windows) computer using the playlist functions of Winamp or XMMS depending on which OS she's running. She has done many compilations before, but none with the convenience and facilities given by your encoder. LAME means we can conserve network bandwidth and disk space, yet preview the discs in reasonably high quality. Of course, we'll be mastering from uncompressed files, but I'm hoping to convince the MD of the company to let selected tracks be available in MP3 format, for no charge, using LAME as the encoder. We're keeping up to date with the CVS tree, and the command used is: lame -d -h -X 6 -Y -Z --cwlimit 12 --lowpass 15.1 --resample 32 -b 128 ... This gives *very* acceptable results in the studio on all the test cases I last tried two months ago, including a very difficult track of choral music. Best wishes, John HW -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
