[MP3 ENCODER] Lame ACM
For those who care, I just found an ACM version of lame here : http://www.davetech.org/Soft1/Files/Audio/lamecom.zip I haven't tested it so far. -- MP3 ENCODER mailing list archive is at: http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
[MP3 ENCODER] ACM / Windows codec
Is there any news of having a Windows Codec based on Lame ? I think I may start one from scratch, since the Microsoft API is available on the MSND online Library. -- MP3 ENCODER mailing list archive is at: http://www.mail-archive.com/mp3encoder%40minnie.cs.adfa.edu.au/
Re: [MP3 ENCODER] Broken MP3s
I know mp3_check can do it... Only keep valid frames from any MP3 files... The problem is that I never released publicly the Win32 build/corrections... And I have no time to do so :( so if you use Linux, you can do it :) - Original Message - From: "Roel VdB" <[EMAIL PROTECTED]> To: "David Bridson" <[EMAIL PROTECTED]> Sent: Saturday, September 30, 2000 8:36 PM Subject: Re: [MP3 ENCODER] Broken MP3s | Hello David, | | Saturday, September 30, 2000, 6:25:31 PM, you wrote: | | DB> I have a couple of MP3s which I encoded with LAME a long time ago. I made | DB> the mistake of putting them on a Zip disk. Now they've got errors in them | DB> which they didn't have in the first place, but Nero 4 is refusing to put | DB> them on CD. Does anyone know if there's a utility anywhere out there which | DB> could possibly fix them? | | 1- find the player that plays them with minimal distortion | 2- write them to wav | 3- burn the wavs with nero | | file://r3mix.net | | | -- | MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) | | | -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Defines
I was looking at the 3.86beta code and was wondering something... What does all the defines (except xxx_H or xxx_INCLUDED) mean ? Would it be possible to have a simple text file explaining all these defines ? Maybe one could try non-default features, but since one don't know what they are for... thx I've found : AMIGA_MPEGA NORES_TEST RH_NOISE_CALC GSM_TABLE_C NOTERMCAP USE_GOGO_SUBBAND -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CBR quality improvement
Is RH_AMP the same as RH_NOISE_CALC ? - Original Message - From: "Robert Hegemann" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 22, 2000 10:57 AM Subject: Re: [MP3 ENCODER] CBR quality improvement Naoki Shibata schrieb am Fre, 22 Sep 2000: > Hi, > > I've just committed some changes to --nspsytune that improves CBR > quality though encoding speed becomes a lot slower. > Changes I made are following: > > 1. Use -X1. > 2. amp_scalefac_bands() amplifies only one sfb at a time. > > I think quality improvement is easily noticable. Encoded quality of > applaud.wav is now very close to that of mp3enc3.1. > > -- > Naoki Shibata e-mail: [EMAIL PROTECTED] compile LAME with RH_AMP, call it with -Y and you get similar results. It's already there for a while and features some better short block noise coloring. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Time-stretching (off topic)
Thanx Alex, >From what I know, a vocoder work in frequency, and analyse the signal. Resampling just add/delete samples from the original so that played at a different samplig freq, it will sound (nearly) the same. But if you resample and play at the same sampling freq, the pitch will be different... So what I need would be something to change the pitch and not the sampling freq (or better the duration of the sample and no pitch difference) - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 14, 2000 4:33 PM Subject: RE: [MP3 ENCODER] Time-stretching (off topic) | Howdy Steve, | | > Does anyone know a good technic/routine to time-stretch a | > buffer of audio data | > (mono channel) ? | | Assuming that you want to keep the pitch the same, phase vocoding comes to | mind. This is an old speech processing trick (thus the vocoder) for | shifting pitch without changing speed or vice versa. Grep around on the | web, and if you don't find anything, I can maybe come up with some | references. I'm sure there must be other (more modern) solutions. | | > Is it better to resample the data according to the | > time-stretching ratio or | > is there some other/better technic ? | | I'm not sure whether phase vocoding is just another name for resampling or | not - I suspect both terms are often used fairly freely. My general | understanding of resampling is that it simply changes the effective sampling | frequency; but (for instance) doubling the number of samples and then | playing back at anything other than double the rate will shift both pitch | and speed. I could be wrong, though. I seem to recall that the process | MIDI tone banks use to play different pitches from the same underlying | sample (which is properly called interpolation?) is referred to as | resampling as well. To say whether that's the same underlying algorithm as | phase vocoding or not, I'd have to read up a bit. | | Boy, can I hedge more than that? | | Hope that helps, | Alex | | -- | MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) | | | -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Correlation & mid/side
trimming and normalization can be done without first scanning the whole file. you'll to tell me how ! for the begining of the stream OK. But at the end, maybe there is a 2s pure digital silence and the another thing... And for normaliztion I don't see how at all, seince you need to need the min/max. Maybe with a circular buffer it would work... -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame re-sampling bug?
Ooops ! But since he mentioned 19, what is the correct magic number ? maybe 10 is another one ? ;) - Original Message - From: "Frank Klemm" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 08, 2000 10:39 PM Subject: Re: [MP3 ENCODER] Lame re-sampling bug? | On Fri, Sep 08, 2000 at 06:48:49PM +0200, Steve Lhomme wrote: | > Hum... | > And if 19 is a magic value, why didn't you use the following ? | > | > BLACKSIZE = 200 | > filter_l = (BLACKSIZE - 19) | > | > | > David: can you run the same test with a stencil 10x bigger? | > | > To do this, change: | > | > | > | > BLACKSIZE = 200change in util.h | > | > filter_l = 191change in util.c | > | > | | 200 - 19 == 191 ??? | | -- | Frank Klemm | | -- | MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) | | | -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Lame re-sampling bug?
Hum... And if 19 is a magic value, why didn't you use the following ? BLACKSIZE = 200 filter_l = (BLACKSIZE - 19) | > David: can you run the same test with a stencil 10x bigger? | > To do this, change: | > | > BLACKSIZE = 200change in util.h | > filter_l = 191change in util.c | > | > If this improves results, then I guess we will have to | > add yet another option :-) | > | | | Ahh yesss... | | As you one remarked - yet another option nobody knows the ideal value | for ;-) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Correlation & mid/side
Well, a pre-processor is what I'm programming. But you can't integrate it with lame since it can't work in real-time/pipe (for DC adjust, trimming, normalisation). - Original Message - From: "Frank Klemm" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 08, 2000 1:20 AM Subject: Re: [MP3 ENCODER] Correlation & mid/side :: | | Anyway I think that the very low frequencies are used in music like :: | | drum&bass with very good sound systems. The infra bass is something I :: | really :: | | like in clubs ;) :: | | Since I want to encode files in good quality (maybe playable in a club) :: | I'd :: | | prefer to keep this and just remove the DC offset... I think it can be :: | :: | then remove all under 5Hz, these freqs you do not need, or it is created :: in :: | another way (by rythm) from transients. :: :: And why not 1Hz ? I'm sure you can make good mechanical effects at this :: frequency ;) Or maybe 0.1Hz ? Well I only need/want to remove the 0Hz I :: prefer to remain consistent with the original on low frequencies (higher :: ones are another question). :: I use a legendre transformation instead of a fourier transformation to remove this stuff. It removes such stuff much better than any frequency domain filtering by best preserving the original signal. May be such functionality should be programmed in a lame preprocessor (lame++ called): * legendre based filtering * fourier based filtering * centering of the signal * detecting best lame mode (-mm, -mj, -mf, -ms) * -- 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 mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] splitting Mp3
If you look at the sources of mp3_check you'll find something that scan MP3 files. So it should be easy to only keep the first frames... - Original Message - From: "Patrick Ndjiki-Nya" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 07, 2000 9:27 AM Subject: [MP3 ENCODER] splitting Mp3 | | Hi all, | | I'd like to present the MP3 data framewise (9 frames at once) to the | decoder I'm implementing. Does anyone know of a piece of C code for | splitting a MP3 file into single frames ? | | Thanks in advance. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Correlation & mid/side
| | Anyway I think that the very low frequencies are used in music like | | drum&bass with very good sound systems. The infra bass is something I | really | | like in clubs ;) | | Since I want to encode files in good quality (maybe playable in a club) | I'd | | prefer to keep this and just remove the DC offset... I think it can be | | then remove all under 5Hz, these freqs you do not need, or it is created in | another way (by rythm) from transients. And why not 1Hz ? I'm sure you can make good mechanical effects at this frequency ;) Or maybe 0.1Hz ? Well I only need/want to remove the 0Hz... I prefer to remain consistent with the original on low frequencies (higher ones are another question). -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Correlation & mid/side
>You should apply a 16 Hz lowpass filter for DC removal. Note that lowest >organ note has 16.3Hz. >Did you hear tones under 16Hz? Did you have speakerboxes that you will give >these low frequencies? I want to made sub-woofer with 16-30Hz range for my >home stereo, but no lower. Well. I think you're talking about a highpass filter ;) Anyway I think that the very low frequencies are used in music like drum&bass with very good sound systems. The infra bass is something I really like in clubs ;) Since I want to encode files in good quality (maybe playable in a club) I'd prefer to keep this and just remove the DC offset... I think it can be computed with a few milliseconds for most files (except more 'mathematical' signals) and I think the ear wouldn't noticethsi variation, and the speaker dynamic would be enhanced. -- 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] 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). You want to compute (remove ?) the DC in real-time ? Well the DC is just the mean of the whole signal, but in real-time you should have a mean on a portion of the signal... I think a good solution would be to have a fixed length circular buffer with all the samples coming in. You'd just need to make the mean of all these samples to get the DC offset. I think the size should be of 10ms or so. Does anyone know the ear latency for that ? I think for speaking it's a few milliseconds (the latency of the speech, not the ear). (I used a lot of 'I think' there...) -- 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] 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] Please stop breaking LAME... ;)
> 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/ )
Re: [MP3 ENCODER] RazorLame 1.1.0 released
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/ )
Re: Re[2]: [MP3 ENCODER] RazorLame 1.1.0 released
> Hello Steve, Hello Holger, > > - possibility to get the options back from the command line > you mean like you enter the command line options in an edit field, > and RazorLame sets the options visually in the options dialog > accordingly? Yep :) > > - possibility to load/save settings in a file > I'll add this to the wish list. I'd do it if I was good at Windows programming... :) -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] RazorLame 1.1.0 released
Two things that would make me change from the command line to RazorLame : - possibility to get the options back from the command line - possibility to load/save settings in a file - Original Message - From: "Holger Dors" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 31, 2000 11:32 AM Subject: [MP3 ENCODER] RazorLame 1.1.0 released > Hello everyone, > > just a quick note that I've release final version 1.1.0 of RazorLame, > available from http://www.dors.de/razorlame/ > > For those who don't know: RazorLame is a Windows front-end for LAME. > > Regards, > Holger Dors mailto:[EMAIL PROTECTED] > > > -- > MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) > > > -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Nr. Frames in mp3 file
I think the only way is to find every frame, and analyse the header. It will give you the frame length with the formula mentionned earlier (sample_per_frame/sampling_frequency). Otherwise, you'll be missing the VBR aspect of files (unless you can get the 'real' bit rate). - Original Message - From: "Patrick Ndjiki-Nya" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 22, 2000 8:27 AM Subject: [MP3 ENCODER] Nr. Frames in mp3 file > > Hello, > > I'd like to determine the number of frames included in an mp3 file > given its size. Using the formula > File_Size/(1152*Bitrate/Sampling_Rate) always leads to a number of > frames that's smaller than the one indicated by an MP3 decoder > (eg. WinAmp) for the same file. Could someone help me out ? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Free Format problem
> > BIT_RATE = 1 means free format. > > This seems kinda confusing -- why use 1 to indicate free when MPEG uses 0? 0 is for 'reserved' (I'm not responsible of this part of the code). > > I've checked the file in hexadecimal, and sometimes I get > > frame header at 202 bytes from the previous instead of 405. > > So I was wondering if this is not a bug of lame or if the > > free format allow this (but I don't think so). > > > > The other possibility is that the real frame size is 202 > > bytes, but then would some of the frames would be separated > > by 405 bytes ? > > Doing the math: > > (576 samp/gr * 1 gr/fr * 62000 bps)/(8 bit/byte * 22050 samp/s) = 202.4 > byte/fr > layer-IIIMPEG-2 bitrateconversionsamp freq You're right ! The correct frame length was 205. I was looking for another same frame header the wrong way (I forgot the PAD_BIT could be different). > Given that this is non-integral, padding will sometimes occur. When the > padding bit is cleared, the frame size will be 202, and when it is set, it > will be 203. Thus, I surmise that there are no 405 byte frames - you just > aren't tracking syncs correctly. Are you factoring in the padding bit? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib layer I/II decoding
> > I had a problem with some files to compute the length in second of a > > frame. I was using various Layer III format and is some cases the formula > > "frame_time = samples / frame_per_second" wouldn't give me the right > > length. I assume it might be comming from this LSF. > > How do you calculate frame_per_second? > > A better formula would be > > frame_time = frame_samples / sampling_frequency > > to get frame_time in seconds. Actually what I told was wrong. I was using this formula, but sometimes with wrong frame_samples values. > The above formula will work regardless of bitrate, free format or otherwise. Right. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Free Format problem
Thanx, that was the info I was missing. Now I get the track length on every example I had (some with free format too, some with different sampling freq, some with different bit rates) - Original Message - From: "Mark Taylor" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 21, 2000 6:25 PM Subject: Re: [MP3 ENCODER] Free Format problem > If sample_freq < 32khz, samples per frame = 576 (not 1152)! > > This the the so-called 'LSF' extension of MPEG: > > 32khz - 48khz: MPEG1 Layer 3 1152 samples per frame > 16khz - 24khz: MPEG2 layer 3 576 samples per frame > 8khz - 12khz: MPEG2.5 layer 3 576 samples per frame. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Free Format problem
I'd like to know your point of view on the "Free format" that lame generates. I've created a free format file with 'lame --freeformat -b 62 file.au". I'm using lame 3.86beta on Win32 compiled locally using MinGW32 with Libsndfile and full speed optimization (all I found usefull in the GCC doc). And it usually works fine. But with free format, it sometimes generate half frames. The file seems to have the following characteristics : MPEG_VERSIONMPEG_2 MPEG_LAYER LAYER_III PROT_BIT0 BIT_RATE1 SAMPLE_FREQ 22050 SAMPLES_PER_FRAME 1152 PAD_BIT 0 PRIV_BIT0 CHANNEL JOINT_STEREO MODE_EXTENSION Intensity OFF / MS ON ID3V2 0 FRAME_LENGTH405 COPYRIGHT 0 ORIGINAL1 EMPHASISNONE CHECK_STATE 1 BIN_STRING 001101100100 BIT_RATE = 1 means free format. I've checked the file in hexadecimal, and sometimes I get frame header at 202 bytes from the previous instead of 405. So I was wondering if this is not a bug of lame or if the free format allow this (but I don't think so). The other possibility is that the real frame size is 202 bytes, but then would some of the frames would be separated by 405 bytes ? any opinions welcomed (I can make the files available if necessary) thx -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mpglib layer I/II decoding
I think for Layer I it's 384.
- Original Message -
From: "Mark Taylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, August 18, 2000 9:57 PM
Subject: Re: [MP3 ENCODER] mpglib layer I/II decoding
>
> The mpglib/mpg123 routine is supposed to return only 1 frame
> of data. 1 frame = 1152 samples MPEG1 layer 3, 576 samples MPEG2 layer3,
> and (not-very-good) the check looks like this:
>
>
> if ((outsize!=576) && (outsize!=1152)) {
> fprintf(stderr,"Oops: mpg123 returned more than one frame! Cant handle
>this... \n");
> }
>
> For layer I, what is the frame size? I think 1024, which is why
> is triggers this message?
>
>
> Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CRC on MP3
I'm highly interrested since, from what I found, the CRC computing is different between Layers and Versions (the amount of data and the order). - Original Message - From: "Frank Klemm" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 18, 2000 2:38 AM Subject: Re: [MP3 ENCODER] CRC on MP3 :: Hi everyone, :: :: I'd like to know where to find some sources or specifications on the CRC used :: on MP3 frames. I know I could get it in the lame sources, but I'd like to know :: first if it's fully compliant ! :: :: This is to integrate the CRC check in mp3_check. :: I've added some improved CRC calculating code to lame (bitstream.c) The code is takes 512 byte for a table and is much faster. Overall performance improvement is nearly not measurable, so I disabled this code. But for an mp3 checker this can be different ... -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Free format
Doh !!! Sorry for the lame question ;) - Original Message - From: "Gabriel Bouvigne" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 18, 2000 8:43 PM Subject: Re: [MP3 ENCODER] Free format > > I'd like to find a free format encoded file. > > Does anyone of you know where I could find one or an encoder that support > free > > format (also known as free bitrate) ? > > > > lame --freeformat -b yourbitrate in.wav out.mp3 -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] mp3 compressed wav files
It's called Rename (dev code is F2) on Windows. You just rename your mp3 files with a wav extension. - Original Message - From: "Sterling Windmill" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 17, 2000 8:53 PM Subject: [MP3 ENCODER] mp3 compressed wav files > Anyone know of any utilities that will convert an mp3 into an mp3 compressed > wav file? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CRC on MP3
Thanx very much ! That was the kind of info I was looking for. Even the ISO spec are available :) (not sure if it's their initial form) And sadly it seems that the CRC is much more complicated than I thought (just scanning a part of the header and the whole audio encoding). - Original Message - From: "Albert Faber" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 17, 2000 12:54 AM Subject: Re: [MP3 ENCODER] CRC on MP3 > Look at Gabriel's home page http://www.mp3-tech.org/ , see section > programmer's corner > > Albert > > http://www.cdex.n3.net/ -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Multi PCM file coding and decoding
> I don't think disk space is a problem these days. > > The (big) advantage of one large mp3file containing the entire album (like > AiD suggests) is that players like winamp don't delay playback when a track > ends and another begins. When using seperate files, Winamp checks playtime, > ID3-TAG and things.. WinAmp have plugins to avoid that. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CRC on MP3
Thanx for the info ! I'd like to have a deeper look at the ISO spec (ISO 13818-3). Any idea where I could find this ? I found this message back in my archives of this list : Gabriel Bouvigne - 04/08/2000 - Re: [MP3 ENCODER] Voice encoding questions - For your problem, there are mainly 2 soulutions: a: downsampling b: using joint stereo. For voice signal, the best joint mode would probably be intensity stereo. But it's not implemented in Lame. You mentionned that you use crc. Are you aware that the ISO crc code is brocken? - -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] CRC on MP3
OK, and what about the bits included in table B5 ?
I saw on this list that the ISO CRC is broken. Is yours OK ?
- Original Message -
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 16, 2000 4:01 PM
Subject: RE: [MP3 ENCODER] CRC on MP3
> Howdy,
>
> > I'd like to know where to find some sources or specifications
> > on the CRC used
> > on MP3 frames. I know I could get it in the lame sources, but
> > I'd like to know
> > first if it's fully compliant !
>
> The polynomial used for CRC on all layers of MPEG audio is given on p.30 of
> ISO/IEC 11172-3:
>
> If the protection bit in the header equals '0', a CRC-check word
> has been inserted in the bitstream just after the header. The error
> detection method used is 'CRC-16' whose generator polynomial is:
>
> G(X) = X^16 + X^15 + X^2 + 1
>
> The bits included into the CRC-check are given by table B.5.
>
> Figure A.9 on p.44 (CRC-check diagram) also represents this polynomial
> graphically.
>
> Here's my code for the polynomial part:
>
> #define CRC16_POLYNOMIAL 0x8005
>
> // Pass length (<32) bits of data through the CRC-16 polynomial with initial
> state crc
> static void CRC_poly(unsigned data, unsigned char length, unsigned short
> *crc)
> {
> bool carry,data_bit;
> unsigned mask;
>
> mask = 1< while(mask >>= 1) {
> data_bit = (data & mask)!=0; // mask off data bit and convert to
> boolean
> carry = (*crc & 0x8000)!=0; // mask off carry bit and convert to
> boolean
> *crc <<= 1; // shift in LSB
> if(carry^data_bit)// if not, we'd be XOR'ing with 0...
> *crc ^= CRC16_POLYNOMIAL;
> }
> }
>
> My code is derived from the ISO 'dist10' source.
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MP3 Programing question... (1 or 2 m's ?) :)
I've ported mp3_check to Win32 and it can scan a whole dir for MP3s and report you all the tracks lenght. But it display this info on the (command-line) screen for each file. Not the whole thing in one file. If you really want just this info on one file, you probably need to use something in a library. - Original Message - From: "David" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, August 12, 2000 2:06 AM Subject: Re: [MP3 ENCODER] MP3 Programing question... (1 or 2 m's ?) :) > Thanks, but .. hmm guess i'de have to do some modifications for it to work > in win32 > and i'm afraid i'm not that handy with c.. .( > and can it handle vbr/abr ? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Win32 build
A quick e-mail just to let you know that the Makefile.DJGPP (lame 3.86) also works fine with MingW32 (Mini GCC for Win32 which uses the MFC to reduce the code size). I'll try to build libsndfile and let you know if it works (if you're interrested). I also want to try the MMX code, but doesn't know where to find "nasm". Any idea ? Is it free ? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: Decoding (was: Re: [MP3 ENCODER] vbr audio degredation)
Were these bug fixes proposed to the mpg123 CVS / dev team ? > Yes, LAME/mpglib has some bug fixes from the original mpg123/mpglib. > Mostly fixes in the 'scfsi' feature, which is used by MP3's produced > by LAME and Xing. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Mulheres... Temos que dar a resposta!
Yep, this is an HTML message with some Javascript code in it. It seems that the script decode another part, looks like a virus :) (or maybe :( That's why HTML or scripting shouldn't be allowed in e-mails... - Original Message - From: "Mark Stephens" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 24, 2000 9:43 PM Subject: RE: [MP3 ENCODER] Mulheres... Temos que dar a resposta! > For me, it contained a VBS scripts that ZoneAlarm (Windows) would not let > run .. I suspect it had a virus in it, but I deleted it as soon as I saw it. > Outlook Express wanted to run it without me opening the message :) MS is so > cool! I suspect it was just a vehical for a script virus. > > Can anyone with a real opsys take a look at the message and see if a script > is attached? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Some observations of vbrtest problem
I've heard some time ago about a software (a plug-in for RealPlayer or something like that) which enhance the sound quality of encoded music (.RA and .MP3) and it mostly process a better phase between signals and generate 'supposed' harmonics. So I think it's a common problem of audio encoding based on frequency. Maybe it would be a good idea to take that in account when encoding. my 2 cents. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] MP3 decoder comparison
The bug in Winamp and I also figured out it is a bit faster (less CPU use). I couldn't really hear the difference anyway... - Original Message - From: "Cavallo de Cavallis" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 17, 2000 7:13 PM Subject: Re: [MP3 ENCODER] MP3 decoder comparison > > Are you sure of that ? Because I use Winamp but with the in_mpg123 output instead > > of the included MP3 decoder (which is also faster). in_mpg123 is a Winamp port > > of MPG123 and it works fine with the VBR+CRC MP3 I encode. > > > what make u choose the in_mpg123 solution ? -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Lame bug found
I think I've found a minor bug in lame. I was trying to encode some files at very low bitrate and I found this bug : the raw pcm part can't encode mono files at low bitrates the encoded files is in mono but the data are doubled (or something like tha, resulting a file of the double size), so when it's played back, it like the sound played slowly (very funny, indeed). I was using some .au files which were taken for raw pcm files (which works fine with j-stereo at higher bitrates). So I converted them to wav and the same parameters (lame -m m --resample 16 -b 16) worked fine, the resulting file was what I expected. So there might be a bug on handling raw pcm stereo. also when I was doing some tests, I noticed this : --- # lame -m j --resample 16 -b 16 fbs.au fbs10.mp3 Assuming raw pcm input file LAME version 3.85 (www.sulaco.org/mp3) Resampling: input=44.1kHz output=16.0kHz Using polyphase lowpass filter, transition band: 581 Hz - 774 Hz Encoding fbs.au to fbs10.mp3 Encoding as 16.0 kHz 16 kbps j-stereo MPEG2 LayerIII (32.0x) qval=5 --- while this one was better --- # lame -m m --resample 16 -B 16 -V 9 --no-hist fbs.au fbs8.mp3 lame: unrec option --no-hist Assuming raw pcm input file LAME version 3.85 (www.sulaco.org/mp3) Resampling: input=44.1kHz output=16.0kHz Using polyphase lowpass filter, transition band: 4452 Hz - 4645 Hz Encoding fbs.au to fbs8.mp3 Encoding as 16.0 kHz VBR(q=9) single-ch MPEG2 LayerIII (14.0x estimated) qval=2 --- Look at the lowpass filter of the first one !!! I've tested the raw pcm problem both on Linux and Win32. -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
