Hi,
I've been using 3.90.2 MSVC compiled that produces smaller mp3s with theoretically the same quality for some time.
There doesn't seem to be such a compile of 3.90.3. Any ideas why?
I note in one thread Dibrom mentioned he'd found which ICL flag was causing the larger mp3s to be produced. Has he produced a 3.90.3 compile which produces smaller files?
If not then I should be fine using the MSVC compile of 3.90.2 with the options
"--alt-preset standard -Z"
???
Cheers.
Full Version: Is there a 3.90.3 MSVC or smaller ICL?
Thanks,
But to be clear, what compiler did you use?
That's a lot slower than the rarewares.org version though. I was hoping for the compile which
dibrom talked about near the middle of this:
http://www.hydrogenaudio.org/forums/index....8&hl=icl&st=25&
He doesn't seem to have made that available, as other compiles (like yours) make smaller files than the rarewares 3.90.3, but are nowhere near as fast.
I see no point in wasting this space, as I encode when I'm not using my PC so a bit of a difference in speed is of no matter.
5% wastage over a large mp3 is several meg. When putting music onto a CD for my car I get 30mins more music with the MSVC compiles at exactly the same sound quality.
Cheers.
But to be clear, what compiler did you use?
That's a lot slower than the rarewares.org version though. I was hoping for the compile which
dibrom talked about near the middle of this:
http://www.hydrogenaudio.org/forums/index....8&hl=icl&st=25&
He doesn't seem to have made that available, as other compiles (like yours) make smaller files than the rarewares 3.90.3, but are nowhere near as fast.
I see no point in wasting this space, as I encode when I'm not using my PC so a bit of a difference in speed is of no matter.
5% wastage over a large mp3 is several meg. When putting music onto a CD for my car I get 30mins more music with the MSVC compiles at exactly the same sound quality.
Cheers.
Dibrom is talking about the size of the lame.exe file. _not_ the mp3 size !!
The pro of MSVC version is a smaller size (for the EXE !). Since now the ICL compile size is smaller, there is no need for the MSVC version.
If your file is smaller with your 3.90.2 version than the 3.90.3 version, the parameters used for encoding aren't the same. Maybe you use a special compile that use a special mode.
The quality is definitely NOT the same than with the 3.90.3 compile.
The pro of MSVC version is a smaller size (for the EXE !). Since now the ICL compile size is smaller, there is no need for the MSVC version.
If your file is smaller with your 3.90.2 version than the 3.90.3 version, the parameters used for encoding aren't the same. Maybe you use a special compile that use a special mode.
The quality is definitely NOT the same than with the 3.90.3 compile.
I think these may be the sort of numbers you're talking about?
The second one is an ICL compile with slightly modified compile options. I'll make this available if you're interested.
CODE
D:\testdir>lame --preset standard 10.wav 10.mp3
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 10.wav to 10.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9781/9784 (100%)| 0:44/ 0:44| 0:44/ 0:44| 5.7256x| 0:00
32 [ 1] *
128 [ 56] %
160 [1047] %%%%%%%%%********
192 [4217] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
224 [2108] %%%%%%%%%%%%%%%%%%%%%%%**********
256 [ 876] %%%%%%%%******
320 [1479] %%%%%%%%%%%%%%%%********
average: 220.2 kbps LR: 6386 (65.27%) MS: 3398 (34.73%)
Writing LAME Tag...done
D:\testdir>lame --preset standard 10.wav 10.mp3
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 10.wav to 10.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9781/9784 (100%)| 0:43/ 0:43| 0:43/ 0:43| 5.8547x| 0:00
32 [ 1] *
128 [ 88] %*
160 [1860] %%%%%%%%%%%%%%%%%%%***********
192 [4102] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
224 [1562] %%%%%%%%%%%%%%%%**********
256 [ 827] %%%%%%%%******
320 [1344] %%%%%%%%%%%%%%%*******
average: 213.4 kbps LR: 6411 (65.53%) MS: 3373 (34.47%)
Writing LAME Tag...done
D:\testdir>
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 10.wav to 10.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9781/9784 (100%)| 0:44/ 0:44| 0:44/ 0:44| 5.7256x| 0:00
32 [ 1] *
128 [ 56] %
160 [1047] %%%%%%%%%********
192 [4217] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
224 [2108] %%%%%%%%%%%%%%%%%%%%%%%**********
256 [ 876] %%%%%%%%******
320 [1479] %%%%%%%%%%%%%%%%********
average: 220.2 kbps LR: 6386 (65.27%) MS: 3398 (34.73%)
Writing LAME Tag...done
D:\testdir>lame --preset standard 10.wav 10.mp3
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 10.wav to 10.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9781/9784 (100%)| 0:43/ 0:43| 0:43/ 0:43| 5.8547x| 0:00
32 [ 1] *
128 [ 88] %*
160 [1860] %%%%%%%%%%%%%%%%%%%***********
192 [4102] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
224 [1562] %%%%%%%%%%%%%%%%**********
256 [ 827] %%%%%%%%******
320 [1344] %%%%%%%%%%%%%%%*******
average: 213.4 kbps LR: 6411 (65.53%) MS: 3373 (34.47%)
Writing LAME Tag...done
D:\testdir>
The second one is an ICL compile with slightly modified compile options. I'll make this available if you're interested.
Yeah, that'd be great. Are those numbers right? The 2nd compile produces smaller files and is quicker?
QUOTE
Dibrom is talking about the size of the lame.exe file. _not_ the mp3 size !!
The pro of MSVC version is a smaller size (for the EXE !). Since now the ICL compile size is smaller, there is no need for the MSVC version.
The pro of MSVC version is a smaller size (for the EXE !). Since now the ICL compile size is smaller, there is no need for the MSVC version.
He's talking about mp3 size. Who cares about .exe size?
QUOTE
If your file is smaller with your 3.90.2 version than the 3.90.3 version, the parameters used for encoding aren't the same. Maybe you use a special compile that use a special mode.
Keep up with the discussions.
QUOTE
The quality is definitely NOT the same than with the 3.90.3 compile.
3.90.2 with the -Z flag is not the same as 3.90.3? Are you sure?
Cheers.
QUOTE(gilden_man @ Mar 16 2004, 02:00 PM)
Yeah, that'd be great. Are those numbers right? The 2nd compile produces smaller files and is quicker?
Yep, the numbers are right.
You can d/l from here: http://homepage.ntlworld.com/jfe1205/LAME/....3modified2.zip
Many thanks, John.
Do you still have those instructions you gave someone (was it you?) about compiling lame yourself?
I can compile it under a sensible environment like UNIX ( no probs, but I've never used a compile
under DOS before.
Cheers.
Do you still have those instructions you gave someone (was it you?) about compiling lame yourself?
I can compile it under a sensible environment like UNIX (
no probs, but I've never used a compileunder DOS before.
Cheers.
QUOTE(gilden_man @ Mar 16 2004, 03:22 PM)
Many thanks, John.
Do you still have those instructions you gave someone (was it you?) about compiling lame yourself?
I can compile it under a sensible environment like UNIX ( no probs, but I've never used a compile
under DOS before.
Cheers.
Do you still have those instructions you gave someone (was it you?) about compiling lame yourself?
I can compile it under a sensible environment like UNIX (
no probs, but I've never used a compileunder DOS before.
Cheers.
Probably.
What compiler?
Well ICL to start with. I'd like to play with these compiler switches myself. Is this straightforward? I'm wondering how a configure script is going to work under DOS
Downloaded ICL 8.0.40 today, but it looks kinda poor.
I did like the 3.90.2 MSVC which produced the small mp3s, too though.
Downloaded ICL 8.0.40 today, but it looks kinda poor.
I did like the 3.90.2 MSVC which produced the small mp3s, too though.
QUOTE(gilden_man @ Mar 16 2004, 03:52 PM)
Well ICL to start with. I'd like to play with these compiler switches myself. Is this straightforward? I'm wondering how a configure script is going to work under DOS
Downloaded ICL 8.0.40 today, but it looks kinda poor.
I did like the 3.90.2 MSVC which produced the small mp3s, too though.
Downloaded ICL 8.0.40 today, but it looks kinda poor.
I did like the 3.90.2 MSVC which produced the small mp3s, too though.
You're going to be using this from the command line? If so, I'll try generating a make file for you. I do all mine from within the VC IDE using the .dsw and .dsp project files.
Just a small note: Dibrom originally used a specific set of ICL4.5 switches, which is the main reason this compiler version and the same switches are still used for the LAME3.90.3 compiles.
Everything which is not compiled with the exact same switches and compiler shouldn't be recommended as it can't be guaranteed to produce the same quality.
Gaining some kbps bitrate savings in trade for less accurate maths is not really an option.
Rather spend your time on working on the most recent lame versions and testing those.
Those should compile "out-of-the-box" if you use MSVC.
dev0
Everything which is not compiled with the exact same switches and compiler shouldn't be recommended as it can't be guaranteed to produce the same quality.
Gaining some kbps bitrate savings in trade for less accurate maths is not really an option.
Rather spend your time on working on the most recent lame versions and testing those.
Those should compile "out-of-the-box" if you use MSVC.
dev0
QUOTE(dev0 @ Mar 16 2004, 04:28 PM)
Gaining some kbps bitrate savings in trade for less accurate maths is not really an option.
I would agree with you, but the change I made forces the compiler to conform to 'C' standards with regards to truncation/rounding of floats, so the accuracy is actually greater and not the other way round.
Please tell me you are NOT using -Qrcd, or that if it was used in the originals, you didn't disable it.
QUOTE
Gaining some kbps bitrate savings in trade for less accurate maths is not really an option.
I thought Dibrom had stated that the ICL optimisations do not follow the C standard and thus the maths in those are less accurate than those in MSVC, which does follow standard C. Despite that, those ICL compiles are the ones he used to make the presets so less accurate or not they are the only compiles guaranteed to conform to his testing.
The objective here, and indeed the material part of the old thread referred to above, was about creating an ICL compile that performed in the same way as the VC6 compile, ie., smaller file sizes, but at the higher speed.
For those who are not familiar with the different way that the Intel compiler operates on floating point to integer conversions, here is an extract from the compiler Help:
The recommended 3.90.2/3 compiles use the -Qrcd option. However, the MSVC compilers conform to C semantics and, therefore, any VC compiles are bound to produce different results to the Intel compilers. IIRC, Dibrom, in the earlier thread, commented that there was unlikely to be any real audible difference between the results produced by the different methods of working. I don't believe this was ABXed, but was the general tone of the conversation.
For those who want Intel speed but with VC reduced file sizes, removal of the '-Qrcd' compile option provides encoded files that are virtually identical to the VC files but produced with Intel speed. The following example demonstrates this:
The compile made available above is not to be posted at Rarewares for general consumption, but does provide a faster alternative for those who would otherwise be using a MSVC compile.
For those who are not familiar with the different way that the Intel compiler operates on floating point to integer conversions, here is an extract from the compiler Help:
QUOTE
Rounding Control Option (-Qrcd)
The Intel compiler uses the -Qrcd option to improve the performance of code that requires floating-point-to-integer conversions. The optimization is obtained by controlling the change of the rounding mode.
The system default floating point rounding mode is round-to-nearest. This means that values are rounded during floating point calculations. However, the C language requires floating point values to be truncated when a conversion to an integer is involved. To do this, the compiler must change the rounding mode to truncation before each floating point-to-integer conversion and change it back afterwards.
The -Qrcd option disables the change to truncation of the rounding mode for all floating point calculations, including floating point-to-integer conversions. Turning on this option can improve performance, but floating point conversions to integer will not conform to C semantics.
The Intel compiler uses the -Qrcd option to improve the performance of code that requires floating-point-to-integer conversions. The optimization is obtained by controlling the change of the rounding mode.
The system default floating point rounding mode is round-to-nearest. This means that values are rounded during floating point calculations. However, the C language requires floating point values to be truncated when a conversion to an integer is involved. To do this, the compiler must change the rounding mode to truncation before each floating point-to-integer conversion and change it back afterwards.
The -Qrcd option disables the change to truncation of the rounding mode for all floating point calculations, including floating point-to-integer conversions. Turning on this option can improve performance, but floating point conversions to integer will not conform to C semantics.
The recommended 3.90.2/3 compiles use the -Qrcd option. However, the MSVC compilers conform to C semantics and, therefore, any VC compiles are bound to produce different results to the Intel compilers. IIRC, Dibrom, in the earlier thread, commented that there was unlikely to be any real audible difference between the results produced by the different methods of working. I don't believe this was ABXed, but was the general tone of the conversation.
For those who want Intel speed but with VC reduced file sizes, removal of the '-Qrcd' compile option provides encoded files that are virtually identical to the VC files but produced with Intel speed. The following example demonstrates this:
CODE
D:\testdir>lame --preset standard 10.wav 10.mp3
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 10.wav to 10.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9781/9784 (100%)| 0:45/ 0:45| 0:45/ 0:45| 5.5733x| 0:00
32 [ 1] *
128 [ 88] %*
160 [1860] %%%%%%%%%%%%%%%%%%%***********
192 [4102] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
224 [1562] %%%%%%%%%%%%%%%%**********
256 [ 827] %%%%%%%%******
320 [1344] %%%%%%%%%%%%%%%*******
average: 213.4 kbps LR: 6411 (65.53%) MS: 3373 (34.47%)
Writing LAME Tag...done
D:\testdir>lamevc --preset standard 10.wav 10.mp3
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 10.wav to 10.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9781/9784 (100%)| 0:59/ 0:59| 0:59/ 0:59| 4.3043x| 0:00
32 [ 1] *
128 [ 88] %*
160 [1862] %%%%%%%%%%%%%%%%%%%***********
192 [4099] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
224 [1562] %%%%%%%%%%%%%%%%**********
256 [ 828] %%%%%%%%******
320 [1344] %%%%%%%%%%%%%%%*******
average: 213.4 kbps LR: 6411 (65.53%) MS: 3373 (34.47%)
Writing LAME Tag...done
D:\testdir>
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 10.wav to 10.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9781/9784 (100%)| 0:45/ 0:45| 0:45/ 0:45| 5.5733x| 0:00
32 [ 1] *
128 [ 88] %*
160 [1860] %%%%%%%%%%%%%%%%%%%***********
192 [4102] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
224 [1562] %%%%%%%%%%%%%%%%**********
256 [ 827] %%%%%%%%******
320 [1344] %%%%%%%%%%%%%%%*******
average: 213.4 kbps LR: 6411 (65.53%) MS: 3373 (34.47%)
Writing LAME Tag...done
D:\testdir>lamevc --preset standard 10.wav 10.mp3
LAME version 3.90.3 MMX (http://www.mp3dev.org/)
CPU features: i387, MMX (ASM used), 3DNow!, SIMD
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 10.wav to 10.mp3
Encoding as 44.1 kHz VBR(q=2) j-stereo MPEG-1 Layer III (ca. 7.3x) qval=2
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
9781/9784 (100%)| 0:59/ 0:59| 0:59/ 0:59| 4.3043x| 0:00
32 [ 1] *
128 [ 88] %*
160 [1862] %%%%%%%%%%%%%%%%%%%***********
192 [4099] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*******************
224 [1562] %%%%%%%%%%%%%%%%**********
256 [ 828] %%%%%%%%******
320 [1344] %%%%%%%%%%%%%%%*******
average: 213.4 kbps LR: 6411 (65.53%) MS: 3373 (34.47%)
Writing LAME Tag...done
D:\testdir>
The compile made available above is not to be posted at Rarewares for general consumption, but does provide a faster alternative for those who would otherwise be using a MSVC compile.
OMG, that really sucks. -Qrcd should never have been used in the first place - it will totally break most float calculations unless the entire program was written with it in mind to start with, and I'm _SURE_ LAME wasn't written in that way.
It'll also make Intel C basically required to get the same results, as no other compiler has something so perverted as that option.
And if I get it correctly, the recommended compiles and the tested alt-presets depend on this behaviour.
The differences not ABX-able? I'd take another look. Nobody ever wondered where those 7kbps were going to?!
Dibrom Dibrom, what have you done...
It'll also make Intel C basically required to get the same results, as no other compiler has something so perverted as that option.
And if I get it correctly, the recommended compiles and the tested alt-presets depend on this behaviour.
The differences not ABX-able? I'd take another look. Nobody ever wondered where those 7kbps were going to?!
Dibrom Dibrom, what have you done...
I always used a mitiok 3.92 ompile with aps -Z cause it gave me slightly smaller files.
At least the problem samples i found behaved exactly the same in 3.90.2 and 3.
I doubt there is really much to ABX.
Wombat
At least the problem samples i found behaved exactly the same in 3.90.2 and 3.
I doubt there is really much to ABX.
Wombat
QUOTE(Garf @ Mar 17 2004, 07:27 AM)
Dibrom Dibrom, what have you done...
I pretty much agree with you on the whole -Qrcd thing, but it was already included in the Makefiles before I even started doing my work on LAME...
The effect that this little option had didn't even come to my attention until I'd already spent quite a bit of time with tuning and decided to start taking a closer look at the makefile stuff...
It's certainly included in this makefile:
QUOTE
Makefile.MSVC: MSVC Makefile for LAME 3.88
which is the makefile included with 3.90, but as '-QIfist', a synonym.
QUOTE(Garf @ Mar 17 2004, 04:27 PM)
Dibrom Dibrom, what have you done...
Well, it's not Dibrom's fault. If it's anybody's fault, it's mine.
It was revision 1.30 of Makefile.MSVC (001120) as /QIfist crept in and
it lastet till 1.52 (020316) as the error was noticed and removed.
QUOTE(Dibrom @ Mar 17 2004, 07:44 PM)
I pretty much agree with you on the whole -Qrcd thing, but it was already included in the Makefiles before I even started doing my work on LAME...
The effect that this little option had didn't even come to my attention until I'd already spent quite a bit of time with tuning and decided to start taking a closer look at the makefile stuff...
The effect that this little option had didn't even come to my attention until I'd already spent quite a bit of time with tuning and decided to start taking a closer look at the makefile stuff...
Hmm, I guess that explains why it worked at all to start with - the expected result of -Qrcd is generally that the program simply doesn't work
A possible solution is to manually fix the affected code so it works in the standard rounding mode, or explicitly call the fast rounder (this is common in other programs which have similar issues). But this is labor-intensive.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.