[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/
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/ )
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/ )
[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] 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] 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] 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] 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 :: | | drumbass 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] 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] 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
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 drumbass 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] 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] 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] 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: [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/ )
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] 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] 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] 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] 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] 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
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 = 1length;
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] 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] 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/ )
[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] 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/ )
