Re: [MP3 ENCODER] Quick joint stereo questions
by the way, LAME doesn't use IS. I believe people have posted here that it is only usefull for lower bitrates. We could try and add IS, but I dont know how usefull it is since most low bitrate applications seem to be in mono. If, when encoding in mid-side, the side channel represents - to within masking thresholds - a straightforward scaling of the mid channel, the encoder should presumably switch to IS. IIRC, phase response in human hearing is poor at very low and very high frequencies (directional sense mostly operates on mid-band frequencies); are the side masking thresholds correspondingly high in the extreme upper and lower bands? -- Mat. My reason for not looking into coding up IS: at 128kbs, I've never seen the FhG encoder us it. They even have an option to disable IS altogether. Also, Rafael (the author of Mpecker) posted a long time ago that he tried IS and it didn't help. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] Table SNR_s bug
Title: Table SNR_s bug
The table of SNR_s for all the frequencies( deduced from psydata) is :
static double TableSNRShort [] =
{
0.15006,0.15006,0.15006,0.15006,0.15006,//Frequency = 16000.
0.15006,0.15006,0.15006,0.15006,0.15006,
0.15006,0.15006,0.15006,0.15006,0.15006,
0.15006,0.15006,0.18007,0.18007,0.18007,
0.18007,0.18007,0.18007,0.18007,0.18007,
0.18007,0.18007,0.18007,0.20003,0.20003,
0.20003,0.20003,0.20003,0.20003,0.20003,
0.20003,0.20003,0.20003,0.20003,0.20003,
0.20003,0.25,0.25,0.25,0.28001,
0.28001,
0.15006,0.15006,0.15006,0.15006,0.15006,//Frequency = 22050.
0.15006,0.15006,0.15006,0.15006,0.15006,
0.15006,0.15006,0.15006,0.18007,0.18007,
0.18007,0.18007,0.18007,0.18007,0.18007,
0.18007,0.18007,0.18007,0.20003,0.20003,
0.20003,0.20003,0.20003,0.20003,0.20003,
0.20003,0.20003,0.20003,0.20003,0.20003,
0.25,0.25,0.25,0.28001,0.28001,
0.28001,0.30012,0.30012,0.30012,0.40006,
0.15006,0.15006,0.15006,0.15006,0.15006,//Frequency = 24000.
0.15006,0.15006,0.15006,0.15006,0.15006,
0.15006,0.15006,0.18007,0.18007,0.18007,
0.18007,0.18007,0.18007,0.18007,0.18007,
0.18007,0.18007,0.20003,0.20003,0.20003,
0.20003,0.20003,0.20003,0.20003,0.20003,
0.20003,0.20003,0.20003,0.20003,0.25,
0.25,0.25,0.28001,0.28001,0.30012,
0.30012,0.30012,0.40006,0.40006,0.40006,
-8.240,-8.240,-8.240,-8.240,-8.240,-8.240,-8.240,-8.240,//Frequency = 32000.
-8.240,-8.240,-7.447,-7.447,-7.447,-7.447,-7.447,-7.447,
-7.447,-7.447,-7.447,-7.447,-6.990,-6.990,-6.990,-6.990,
-6.990,-6.990,-6.990,-6.990,-6.990,-6.990,-6.020,-6.020,
-6.020,-6.020,-5.229,-5.229,-5.229,-5.229,-4.559,-4.559,
-3.980,-3.980,
-8.240,-8.240,-8.240,-8.240,-8.240,-8.240,-8.240,-8.240,//Frequency = 44100.
-8.240,-8.240,-7.447,-7.447,-7.447,-7.447,-7.447,-7.447,
-7.447,-7.447,-7.447,-7.447,-6.990,-6.990,-6.990,-6.990,
-6.990,-6.990,-6.990,-6.990,-6.990,-6.990,-6.020,-6.020,
-6.020,-6.020,-5.229,-5.229,-5.229,-5.229,-4.559,
-8.240,-8.240,-8.240,-8.240,-8.240,-8.240,-8.240,-8.240,//Frequency = 48000.
-8.240,-8.240,-7.447,-7.447,-7.447,-7.447,-7.447,-7.447,
-7.447,-7.447,-7.447,-7.447,-6.990,-6.990,-6.990,-6.990,
-6.990,-6.990,-6.990,-6.990,-6.990,-6.990,-6.020,-6.020,
-6.020,-6.020,-5.229,-5.229,-5.229,-5.229
};
In the psy model, we use SNR_s with the formula
nb[b] = ecb[b] * norm_s[b] * exp( (double) SNR_s[b] * LN_TO_LOG10 );
You can easily notice that
exp(-8,240 * LN_TO_LOG10) = 0.15
exp(-7,447 * LN_TO_LOG10) = 0.18
It seems that the exponential calculation is already included in the SNR_s table for MPEG-2,
but not for MPEG-1.
Lionel
Re: [MP3 ENCODER] lame 3.36beta
Oh, btw, I've been hinted by one of my (LAME port) users that putting f.ex; extern int __buffsize=10; now what kind of importable, dubious hack is _this_?!!! greetings, -gerhard -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] var bitrate quality
Is the variable bitrate quality in any way not as good as constant bitrate? Fraunhofer's new encoder only encodes var bitrates in fast mode.
[MP3 ENCODER] Hann Window
Does anybody know why the Hann window defined by : window[i] =0.5*(1-cos(2.0*pi*(i-0.5)/BLKSIZE)); in the ISO doc became window[i] =0.5*(1-cos(2.0*pi*(i+0.5)/BLKSIZE)); in LAME ? Lionel -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Table SNR_s bug
...
In the psy model, we use SNR_s with the formula
nb[b] = ecb[b] * norm_s[b] * exp( (double) SNR_s[b] * LN_TO_LOG10 );
You can easily notice that
exp(-8,240 * LN_TO_LOG10) = 0.15
exp(-7,447 * LN_TO_LOG10) = 0.18
It seems that the exponential calculation is already included in the SNR_s
table for MPEG-2,
but not for MPEG-1.
Lionel
-=- MIME -=-
CE MESSAGE EST AU FORMAT MIME. Comme votre lecteur de courrier ne comprend pas
ce format, il se peut que tout ou partie de ce message soit illisible.
--MS_Mac_OE_3023866806_186234_MIME_Part
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
The table of SNR_s for all the frequencies( deduced from psydata) is :
static double TableSNRShort [] =3D
{
0.15006 , 0.15006 , 0.15006 , 0.15006 , 0.15006 , // F=
r
equency =3D 16000.
0.15006 , 0.15006 , 0.15006 , 0.15006 , 0.15006 ,
0.15006 , 0.15006 , 0.15006 , 0.15006 , 0.15006 ,
0.15006 , 0.15006 , 0.18007 , 0.18007 , 0.18007 ,
0.18007 , 0.18007 , 0.18007 , 0.18007 , 0.18007 ,
0.18007 , 0.18007 , 0.18007 , 0.20003 , 0.20003 ,
0.20003 , 0.20003 , 0.20003 , 0.20003 , 0.20003 ,
0.20003 , 0.20003 , 0.20003 , 0.20003 , 0.20003 ,
0.20003 , 0.25 , 0.25 , 0.25 , 0.28001 ,
0.28001 ,
0.15006 , 0.15006 , 0.15006 , 0.15006 , 0.15006 , // F=
r
equency =3D 22050.
0.15006 , 0.15006 , 0.15006 , 0.15006 , 0.15006 ,
0.15006 , 0.15006 , 0.15006 , 0.18007 , 0.18007 ,
0.18007 , 0.18007 , 0.18007 , 0.18007 , 0.18007 ,
0.18007 , 0.18007 , 0.18007 , 0.20003 , 0.20003 ,
0.20003 , 0.20003 , 0.20003 , 0.20003 , 0.20003 ,
0.20003 , 0.20003 , 0.20003 , 0.20003 , 0.20003 ,
0.25 , 0.25 , 0.25 , 0.28001 , 0.28001 ,
0.28001 , 0.30012 , 0.30012 , 0.30012 , 0.40006 ,
0.15006 , 0.15006 , 0.15006 , 0.15006 , 0.15006 , // F=
r
equency =3D 24000.
0.15006 , 0.15006 , 0.15006 , 0.15006 , 0.15006 ,
0.15006 , 0.15006 , 0.18007 , 0.18007 , 0.18007 ,
0.18007 , 0.18007 , 0.18007 , 0.18007 , 0.18007 ,
0.18007 , 0.18007 , 0.20003 , 0.20003 , 0.20003 ,
0.20003 , 0.20003 , 0.20003 , 0.20003 , 0.20003 ,
0.20003 , 0.20003 , 0.20003 , 0.20003 , 0.25 ,
0.25 , 0.25 , 0.28001 , 0.28001 , 0.30012 ,
0.30012 , 0.30012 , 0.40006 , 0.40006 , 0.40006 ,
-8.240 , -8.240 , -8.240 , -8.240 , -8.240 , -8.240 , -8.240 , -8.240 , /=
/
Frequency =3D 32000.
-8.240 , -8.240 , -7.447 , -7.447 , -7.447 , -7.447 , -7.447 , -7.447 ,
-7.447 , -7.447 , -7.447 , -7.447 , -6.990 , -6.990 , -6.990 , -6.990 ,
-6.990 , -6.990 , -6.990 , -6.990 , -6.990 , -6.990 , -6.020 , -6.020 ,
-6.020 , -6.020 , -5.229 , -5.229 , -5.229 , -5.229 , -4.559 , -4.559 ,
-3.980 , -3.980 ,
-8.240 , -8.240 , -8.240 , -8.240 , -8.240 , -8.240 , -8.240 , -8.240 , /=
/
Frequency =3D 44100.
-8.240 , -8.240 , -7.447 , -7.447 , -7.447 , -7.447 , -7.447 , -7.447 ,
-7.447 , -7.447 , -7.447 , -7.447 , -6.990 , -6.990 , -6.990 , -6.990 ,
-6.990 , -6.990 , -6.990 , -6.990 , -6.990 , -6.990 , -6.020 , -6.020 ,
-6.020 , -6.020 , -5.229 , -5.229 , -5.229 , -5.229 , -4.559 ,
-8.240 , -8.240 , -8.240 , -8.240 , -8.240 , -8.240 , -8.240 , -8.240 , /=
/
Frequency =3D 48000.
-8.240 , -8.240 , -7.447 , -7.447 , -7.447 , -7.447 , -7.447 , -7.447 ,
-7.447 , -7.447 , -7.447 , -7.447 , -6.990 , -6.990 , -6.990 , -6.990 ,
-6.990 , -6.990 , -6.990 , -6.990 , -6.990 , -6.990 , -6.020 , -6.020 ,
-6.020 , -6.020 , -5.229 , -5.229 , -5.229 , -5.229
};
In the psy model, we use SNR_s with the formula
nb[b] =3D ecb[b] * norm_s[b] * exp( (double) SNR_s[b] * LN_TO_LOG10 );
You can easily notice that
exp(-8,240 * LN_TO_LOG10) =3D 0.15
exp(-7,447 * LN_TO_LOG10) =3D 0.18
=8A
It seems that the exponential calculation is already included in the SNR_s
table for MPEG-2,
but not for MPEG-1.
Lionel
--MS_Mac_OE_3023866806_186234_MIME_Part
Content-type: text/html; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
HTML
HEAD
TITLETable SNR_s bug/TITLE
/HEAD
BODY BGCOLOR=3D"#FF"
TTThe table of SNR_s for all the frequencies( deduced from psydata) is :=
BR
BR
static double TableSNRShort [] =3DBR
{BR
nbsp;0.15006nbsp;,nbsp;0.15006nbsp;,nbsp;0.15006nbsp;,nb=
sp;0.15006nbsp;,nbsp;0.15006nbsp;,nbsp;//nbsp;Frequency =3D 16000=
.BR
nbsp;0.15006nbsp;,nbsp;0.15006nbsp;,nbsp;0.15006nbsp;,nb=
sp;0.15006nbsp;,nbsp;0.15006nbsp;,BR
nbsp;0.15006nbsp;,nbsp;0.15006nbsp;,nbsp;0.15006nbsp;,nb=
sp;0.15006nbsp;,nbsp;0.15006nbsp;,BR
Re: Re : [MP3 ENCODER] spreading function buggy?
X-Authentication-Warning: cs.csoft.net: $s=geek.rcc.se doesn't match $[EMAIL PROTECTED] X-Authentication-Warning: geek.rcc.se: majordom set sender to [EMAIL PROTECTED] using -f Date: Wed, 27 Oct 1999 10:46:24 +0200 From: "Lionel Bonnet" [EMAIL PROTECTED] X-Priority: 3 Content-type: multipart/alternative; boundary="MS_Mac_OE_3023865984_136826_MIME_Part" Sender: [EMAIL PROTECTED] Precedence: bulk Reply-To: [EMAIL PROTECTED] X-UIDL: `kd9d'gd9_I5!!g,md9 I would suggest: if (j=i) tempy = (bval_l[j] - bval_l[i])*(-10); elsetempy = (bval_l[j] - bval_l[i])*25; if (tempy = -60.0) s3_l[i][j] = 0.0; elses3_l[i][j] = exp( tempy*LN_TO_LOG10 ); but this will need a lot of testing. One additional confusion: in the ISO doc, the meaning of i and j seem to be reversed from the ISO code. Mark It 's not true. The slope is for the spreading function s3_l, not for tempy or tempx. You must test the slope on s3_l = 15.81 + 7.5 and see that it is 25db and -10db. Can you explain this a little more? My reading of the paper and the figure is that the slope of s3_l is -10db/bark, 25db/bark and that is what I am suggesting above. The formula in the ISO code and the paper, SF(x) = 15.81 + 7.5... looks like an approximation of the 10db/25db curve. I will have to plot this function today. Also, in the ISO code, the SF(x) formula is used to compute tempy from tempx. But in the "modifications for layer III" they advocate replacing tempy (not tempx!) with a different value, and thus ignoring the SF(x) formula. Here are some values for the spreading function for partition band i=31. s3_l in db. (before taking the exponential) psy-model 2, layer 3 formula: i,j 31 28 -18.244921 i,j 31 29 -13.595852 i,j 31 30 -3.452440 i,j 31 31 -0.00 i,j 31 32 -10.261171 i,j 31 33 -31.815638 i,j 31 34 -55.686492 psy-model 2, layer 2 formula: i,j 31 28-14.744852 i,j 31 29 -8.291966 i,j 31 30-0.974892 i,j 31 31-0.00 i,j 31 32 -1.181771 i,j 31 33 -4.615616 i,j 31 34 -9.927099 Note that the layer 3 formula drops off *very* quickly for higher frequencies (ji), which is clearly incorrect since this slope should be less than the ji slope. Ther is another way to see it : you can calculate the norm_l coefficient by norm_l[i] = 1/(sum of s3_l[i][j]). With the current version(don't change anything), you will find the normalisation coefficient of table C.7. The formula is correct with the tables given in the ISO doc and with the Painter article. -=- MIME -=- CE MESSAGE EST AU FORMAT MIME. Comme votre lecteur de courrier ne comprend pas ce format, il se peut que tout ou partie de ce message soit illisible. --MS_Mac_OE_3023865984_136826_MIME_Part Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable I would suggest: if (j=3Di) tempy =3D (bval_l[j] - bval_l[i])*(-10); elsetempy =3D (bval_l[j] - bval_l[i])*25; if (tempy =3D -60.0) s3_l[i][j] =3D 0.0; elses3_l[i][j] =3D exp( tempy*LN_TO_LOG10 ); but this will need a lot of testing. One additional confusion: in the ISO doc, the meaning of i and j seem to be reversed from the ISO code. Mark It 's not true. The slope is for the spreading function s3_l, not for tempy or tempx. You must test the slope on s3_l =3D 15.81 + 7.5 =8A and see that it i= s 25db and -10db. Ther is another way to see it : you can calculate the norm_l coefficient by norm_l[i] =3D 1/(sum of s3_l[i][j]). With the current version(don't change anything), you will find the normalisation coefficient of table C.7. The formula is correct with the tables given in the ISO doc and with the Painte= r article. Lionel --MS_Mac_OE_3023865984_136826_MIME_Part Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable HTML HEAD TITLERe : [MP3 ENCODER] spreading function buggy?/TITLE /HEAD BODY BGCOLOR=3D"#FF" TTBR BR gt; I would suggest:BR gt;BR gt; nbsp;nbsp;nbsp;if (jgt;=3Di) tempy =3D (bval_l[j] - bval_l[i])*(-10);= BR gt; nbsp;nbsp;nbsp;else nbsp;nbsp;nbsp;tempy =3D (bval_l[j] - bval_l[i= ])*25;BR gt;BR gt; nbsp;nbsp;nbsp;if (tempy lt;=3D -60.0) s3_l[i][j] =3D 0.0;BR gt; nbsp;nbsp;nbsp;else nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp= ;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;s3_l[i][j] =3D exp( tempy*LN_TO_LOG= 10 );BR gt;BR gt; but this will need a lot of testing.BR gt;BR gt; One additional confusion: in the ISO doc, the meaning of i and jBR gt; seem to be reversed from the ISO code.BR gt;BR gt; MarkBR BR It 's not true. The slope is for the spreading function s3_l, not for tempy= BR or tempx. You must test the slope on s3_l =3D 15.81 + 7.5 =8A and see that it i= sBR 25db and -10db.BR BR Ther is another way to see it : you can calculate the norm_l coefficient by= BR norm_l[i] =3D 1/(sum of s3_l[i][j]). With the current version(don't changeBR= anything),
Re: [MP3 ENCODER] var bitrate quality
From: "Francois du Toit" [EMAIL PROTECTED] Date: Wed, 27 Oct 1999 16:24:23 +0200 Is the variable bitrate quality in any way not as good as constant bitrate? Fraunhofer's new encoder only encodes var bitrates in fast mode. -=- MIME -=- This is a multi-part message in MIME format. --=_NextPart_000_0005_01BF2097.BAF608A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is the variable bitrate quality in any way not as good as constant = bitrate? Fraunhofer's new encoder only encodes var bitrates in fast mode.=20 --=_NextPart_000_0005_01BF2097.BAF608A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable !DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" HTMLHEAD META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR STYLE/STYLE /HEAD BODY bgColor=3D#ff DIVFONT face=3DArial size=3D2Is the variable bitrate quality in any = way not as=20 good as constant bitrate?/FONT/DIV DIVFONT face=3DArial size=3D2Fraunhofer's new encoder only encodes = var bitrates=20 in fast mode. /FONT/DIV/BODY/HTML --=_NextPart_000_0005_01BF2097.BAF608A0-- -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ ) As a replacement for the bitreservoir, I think VBR does pretty well. That is: encode all frames at 112kbs, except when needed allow the bits to be increased above 112kbs. At fixed bitrates, MP3 encoders will try to do this by using the bitreservoir, but it will not work if the bit reservoir runs out as it often does. Note that at fixed 128kbs, the average frame is about 112kbs, and the extra bits are added to the bit reservoir to build it up. The more common use of VBR is for maximum compression at a given quality. But this requires a *very* good psy-model, since the LAME VBR can now shape the noise to almost exactly match the output of the psy-model. Flaws in the psy-model then become very noticable. I wouldn't recommend using LAME in this mode just yet. We are making almost weekly improvments though, so maybe we will get there. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Hann Window
Does anybody know why the Hann window defined by : window[i] =0.5*(1-cos(2.0*pi*(i-0.5)/BLKSIZE)); in the ISO doc became window[i] =0.5*(1-cos(2.0*pi*(i+0.5)/BLKSIZE)); in LAME ? Lionel -- In the ISO docs, i=1..1024, code uses normal C convention: i=0..1023 Leonid found and fixed this bug last august. Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] var bitrate quality
The more common use of VBR is for maximum compression at a given quality. But this requires a *very* good psy-model, since the LAME VBR can now shape the noise to almost exactly match the output of the psy-model. Flaws in the psy-model then become very noticable. I wouldn't recommend using LAME in this mode just yet. We are making almost weekly improvments though, so maybe we will get there. Thanks for the info, Mark, this is very helpful. My question now would be: how would you rate the psy model of the newest Xing and Fraunhofer encoders in VBR mode? Would you use VBR or CBR with those encoders? (Assuming quality is the number 1 issue). And along those same lines: at this point, what would you recommend as the best encoder for getting the best quality at a bitrate (or avg. bitrate using VBR) of 192 kbps or less? Thanks, Russell Davis -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.36beta
Kimmo Mustonen: Much code cleanup and Amiga updates Hummm, any chance of telling me which changes he did? I'd be very interested. ;) Why's that? Well, not all my patches were included, but some of them were Because I'm doing a semi-official port of LAME for Amiga... ;) Check out The Amiga Alternative Audio Page - http://csc.smsu.edu/~strauser/audio.html [...] Oh, btw, I've been hinted by one of my (LAME port) users that putting f.ex; extern int __buffsize=10; That's something that I'm really interested. I noticed myself that there are far too many unnecessary context switches for PPC version to be efficient. I must try if even 1 meg or something would give even more performance. Yes, but I think it might be wiser setting different sizes for input/output for efficient streaming using the setvbuf() function. - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] lame 3.36beta
Oh, btw, I've been hinted by one of my (LAME port) users that putting f.ex; extern int __buffsize=10; now what kind of importable, dubious hack is _this_?!!! It's no hack, it's pure ANSI .. it's the reference buffer value for input/output. - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: Re[2]: [MP3 ENCODER] lame 3.36beta
Hi All...
Sergey wrote:
I have changed thus:
===
int fskip(FILE *sf,long num_bytes,int dummy)
{
char *data = (char *) malloc(num_bytes);
return (num_bytes != fread(data,(size_t)1,(size_t)num_bytes,sf));
free(data);
}
===
I don't know if this is the literal code, or just a snip...
If it is literal, you'll have to do this a little differently cause you are
returning before you free the malloced space. Memory leak!
-Ilana Rudnik
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: Re[2]: [MP3 ENCODER] lame 3.36beta
On Wed, 27 Oct 1999, Ilana Rudnik wrote:
int fskip(FILE *sf,long num_bytes,int dummy)
{
char *data = (char *) malloc(num_bytes);
return (num_bytes != fread(data,(size_t)1,(size_t)num_bytes,sf));
free(data);
}
===
I don't know if this is the literal code, or just a snip...
If it is literal, you'll have to do this a little differently cause you are
returning before you free the malloced space. Memory leak!
...and using the allocated memory without bothering to check whether the
allocation was successful or not.
Well as this was only a quick fix this just might be acceptable but
checking it really isn't too much work.
Regards,
Kimmo Mustonen
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] Resampling at wrong pitch/speed: bug?
Hi all, just gave it a try: lame -b 128 -X5 -v -V 4 -h -k -d --resample 48 in.wav out48.mp3 The .wav file was grabbed from an audio-CD (44.1 kHz). mp3 sounds horrible, way too fast. Is this a feature or should the resampled file sound like the original? The FhG resamples to 48 kHz without any noticeable speed-up. FhG does the resampling even by default, if you choose 320 kBit. Ok, it's lame 3.35, haven't tried out the 3.36 but since this is not mentioned in the history-file, I suppose 3.36 behaves the same. Kind regardsFrederick The bug is that the error message "Error: resample code not yet written!" was not being printed :-) I think the upsample to 48kHz at 320kbs because (IIRC) a 44.1kHz and lower 320kbs frame violates some ISO restrictions on max buffer sizes. Fortunatly most decoders allow for larger buffer sizes. Other than that, is there any reason to upsample? I have been thinking about the downsampling: I think we should just add a simple linear downsampler, with the tapered lowpass sox type filter applied directly to our MDCT coefficients. This would require very little extra work, and my guess is the aliasing from linear downsampling is insignificant compared to what MPEG2 compression does to the high frequencies. Has anyone who uses sox/MPEG2 noticed a difference between the sox 'resample' option and 'polyphase'? Mark -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re : [MP3 ENCODER] spreading function buggy?
I would suggest: if (j=i) tempy = (bval_l[j] - bval_l[i])*(-10); elsetempy = (bval_l[j] - bval_l[i])*25; if (tempy = -60.0) s3_l[i][j] = 0.0; elses3_l[i][j] = exp( tempy*LN_TO_LOG10 ); but this will need a lot of testing. One additional confusion: in the ISO doc, the meaning of i and j seem to be reversed from the ISO code. Mark It 's not true. The slope is for the spreading function s3_l, not for tempy or tempx. You must test the slope on s3_l = 15.81 + 7.5 and see that it is 25db and -10db. Can you explain this a little more? My reading of the paper and the figure is that the slope of s3_l is -10db/bark, 25db/bark and that is what I am suggesting above. The formula in the ISO code and the paper, SF(x) = 15.81 + 7.5... looks like an approximation of the 10db/25db curve. I will have to plot this function today. Also, in the ISO code, the SF(x) formula is used to compute tempy from tempx. But in the "modifications for layer III" they advocate replacing tempy (not tempx!) with a different value, and thus ignoring the SF(x) formula. Here are some values for the spreading function for partition band i=31. s3_l in db. (before taking the exponential) psy-model 2, layer 3 formula: i,j 31 28 -18.244921 i,j 31 29 -13.595852 i,j 31 30 -3.452440 i,j 31 31 -0.00 i,j 31 32 -10.261171 i,j 31 33 -31.815638 i,j 31 34 -55.686492 psy-model 2, layer 2 formula: i,j 31 28-14.744852 i,j 31 29 -8.291966 i,j 31 30-0.974892 i,j 31 31-0.00 i,j 31 32 -1.181771 i,j 31 33 -4.615616 i,j 31 34 -9.927099 For me the slopes of 25/-10 dB just means that s3_l should be -25 when the difference of bval is -1 and -10 when the difference of bval is 1. These are slopes around the current band of the calcul. With the formula you suggested, the slopes will be different. Rather than i and j, print the value of bval[j] and you will see if the value of s3_l is around -25 for bval[j] = bval[i]-1, which would make a local slope of 25dB/bark under zero, same interpretation above 0.(s3_l is a parabola with maximum value of 0 at 0) . If you want to decrease the masking by increasing the coefficients 3 and 1.5, you may not mask data that should be masked.(increasing the coefficients 3 and 1.5 increases the slopes of the spreading funtion) I applied the coefficients 3 and 1.5 to the layer II and had the impression the results were better(i can hear it and recognize the best file when both are played randomly) than with 1.05( advice for Toolame) but putting -10 and 25 as coefficients for tempy is "non-sense". For me, the advices for the psy model(tempy coefficients) of layer III should be applied to the layer II model(for Toolame).The psy model was improved between the two layers but it's the same model and there is no reason to have different ways of calculating spreading function, ... . For the SNR_s table, i have not tested it yet, but i would be very surprised if it's a coincidence. I often have the feeling that the only advantage of Fhg over us is that they know all the bugs they have put in the docs and code. Lionel -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
RE: Re[2]: [MP3 ENCODER] lame 3.36beta
Regarding the code, below -- perhaps I'm missing something, but why not
use fseek? There should be no problem fseeking *forward* in either a file
or a pipe. It's seeking *backward* which is a problem, and there is no
way to solve that problem without buffering the file from the start.
fseek is pretty much guaranteed to be more efficient than the combination
of malloc/fread/free, below. As demonstrated, it's also less prone to
bugs.
Am I completely missing the point?
Tim.
On Thu, 28 Oct 1999, Kimmo Mustonen wrote:
On Wed, 27 Oct 1999, Ilana Rudnik wrote:
int fskip(FILE *sf,long num_bytes,int dummy)
{
char *data = (char *) malloc(num_bytes);
return (num_bytes != fread(data,(size_t)1,(size_t)num_bytes,sf));
free(data);
}
===
I don't know if this is the literal code, or just a snip...
If it is literal, you'll have to do this a little differently cause you are
returning before you free the malloced space. Memory leak!
...and using the allocated memory without bothering to check whether the
allocation was successful or not.
Well as this was only a quick fix this just might be acceptable but
checking it really isn't too much work.
Regards,
Kimmo Mustonen
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
[MP3 ENCODER] File IO buffering.
Concerning the file IO buffering discussed earlier, I'd suggest a scheme somewhat resembling the following so as to scalably buffer at a rate that is actually considering what amount of data we input/output. Using setvbuf() we set buffers thusly; Input: (samplerate * 2) * number_of_channels Output: (bitrate / 8) * 1024 This should imho make an ideal setting for buffering, both for streaming and normal operation... ;) - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
Re: [MP3 ENCODER] File IO buffering.
Concerning the file IO buffering discussed earlier, I'd suggest a scheme somewhat resembling the following so as to scalably buffer at a rate that is actually considering what amount of data we input/output. Using setvbuf() we set buffers thusly; Hummm, ofcos, when reading up on how setvbuf() works I see that it is not recommended that one uses it after the file has been used. Doing it this way (which I still think we should) would then mean one would have to close the file after getting all the info needed from it's headers, reopen it, set the buffers, then skip to the beginning of the data. ..a little extra work, but I think it would be preferable to a fixed size buffer. - CISC -- MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
