LAME 3.99 is out, 2012-02-28: version 3.99.5 has been released Options

[Broadway]

Revised version which includes the extended VRB Quality range is here for testing, if those who are interested would be so kind.

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip

On the 'About' page, I have added a note next to the compile date to indicate whether it is a 32 bit, or 64 bit compile.

Runnig fine now - even on my system ;-)
No problems so far!

Thank you!

[john33]

Revised version which includes the extended VRB Quality range is here for testing, if those who are interested would be so kind.

http://www.rarewares.org/files/mp3/lamedro...2-3.99.1-64.zip

On the 'About' page, I have added a note next to the compile date to indicate whether it is a 32 bit, or 64 bit compile.

Runnig fine now - even on my system ;-)
No problems so far!

Thank you!

Ah! Now that is good news. Let's hope it stays that way. If all is well over the next 24 hours, I'll put this and the new 32 bit compile up on Rarewares.

Thanks to all for your help.

[Broadway]

...
Let's hope it stays that way. If all is well over the next 24 hours, I'll put this and the new 32 bit compile up on Rarewares.
...

I tested several files abr, cbr and vbr...still working fine!

[Anakunda]

Hello I still think there's some tagging bug in L3.99.1.
Especially it concerns writting encoder metadata to Lame header.
Convert anything with Lame 3.99.1 and look to metadata by MediaInfo or another metadata viewer.
Seems to me the encoder field is kinda corrupted. I get various results for the latest Lame build from Rarewarez.
On my test encode I got this:

Writing library : LAME3.99.1ŞŞŞŞŞŞŞŞŞŞ

This looks like the encoder doesnot zero terminate the encoder field properly, or even this value is written corrupted.
On another attempt the created mp3 even has no Lame version reported by MediaInfo.

In foobar I always get this value:

Tool : L3.99r

which is kinda nonstandard too. Please fix it.



This post has been edited by Anakunda: Nov 9 2011, 16:54

[lock67ca]

With the latest build, the encoder setting in iTunes is listed as Unknown. Encspot has enccoder as Gogo(after 3.0). MediaInfo has 3.99.1 and Mr Questionman is 3.99, which I assume is normal. foobar is 3.99r, which is also correct.

Using the 32 bit version.

This post has been edited by lock67ca: Nov 9 2011, 17:40

[Anakunda]

For me the string is as shown on the image above. Encoded with Lame 3.99.1 64bit from foobar. Using MediaInfo 0.7.50.
The nonsense characters behind the version string infer that there's something wrong with tagging in this version (or with MediaInfo?).
If I peek in metadata of random MP3 encoded by older version of Lame the version string looks correct (no trailing garbage chars).

Encoded raw WAV file from commandline. Now the version string reported by MediaInfo is

Writing library : LAMEŞŞqŞ“‘§d�FĄĽ;óŇ

The WAV and resulting MP3 uploaded here:

CODE

http://www.mediafire.com/?ynz19sryizkrby9

Can anybody confirm the same problem?

// Yet another edit

This problem deals with 64 bit LAME backend from Rarewarez.
Tried to encode with 32bit CLI and the resulting MP3 version tag looks nice.
Please for recompile with fixed tagging.

This post has been edited by Anakunda: Nov 9 2011, 17:31

[Wombat]

I reported the encoder settings value shown wrong in Post #319 already http://www.hydrogenaudio.org/forums/index....st&p=774849
The version string Windows 7 internal file details report is "3.99."

[john33]

This post is basically directed at Robert, but anyone else is welcome to join in.

Relating to the comments about speeds of different compiles, I've been playing around with different options. I've come up with three compiles of the basic lame.exe which I've tested on my System 1 (the Phenom II x4 840) and System 3 (the i7 920). So the first one is firmly in the AMD camp and the second in the Intel camp.

The three compiles are:

lame-1, the standard nasm enabled 32 bit Intel compile (icc_patch run before testing on both systems);
lame-2, a 32 bit compile, without nasm support, but with the preprocessor directives HAVE_XMMINTRIN_H and MIN_ARCH_SSE specified (icc_patch run before testing on both systems); and
lame-64, the standard 64 bit compile.

On System 1:
lame-1 - 31.569x
lame-2 - 34.306x
lame-64 - 40.514x

On System 3:
lame-1 - 44.251x
lame-2 - 51.293x
lame-64 - 57.766x

So, the basic question would have to be, is it time to retire the nasm code from all builds? Is it reasonable to assume that MIN_ARCH_SSE compiles will run on all systems that the nasm builds run on? My feeling is yes to both questions, but I would welcome other input and opinions.

[robert]

The NASM compiles still run on older chips like AthlonXP or older Pentiums, the SSE compiles likely not. For 64-bit compiles, the NASM one is not needed anymore.

re media info: the lame info tag has a 9 bytes field for "Encoder short version string".
For versions with patch level > 0 we write: L<Major Version>.<Minor Version>[a,b or r]<Patch level>
else: LAME<Major Version>.<Minor Version>[a,b,r or blank]
In all cases, this string gets truncated after 9 bytes.

This post has been edited by robert: Nov 9 2011, 17:55

[lvqcl]

john33, please compile NASM version with SSE enabled and fast FP (/arch:SSE /fp:fast). I suspect that it will be faster than now.

[john33]

john33, please compile NASM version with SSE enabled and fast FP (/arch:SSE /fp:fast). I suspect that it will be faster than now.

Exactly the same on both systems. /fp:fast was already set. In fact, the second compile without nasm support and with the preprocessor directives removed is still marginally faster on both systems!

[nao]

My test (@Sandy Bridge, gcc 4.2.1):

CODE

NASM build
fp math TAKEHIRO_IEEE754_HACK speed
_______ _____________________ _____
x87     yes                   59.7x
x87     no                    58.5x
SSE     yes                   62.1x
SSE     no                    67.7x

MIN_ARCH_SSE build
fp math TAKEHIRO_IEEE754_HACK speed
_______ _____________________ _____
SSE     yes                   55.1x
SSE     no                    56.3x

Here, NASM + SSE fp math + no TAKEHIRO_IEEE754_HACK build is the fastest. This is expected result because the nasm code is faster than the SSE intrinsics code used by MIN_ARCH_SSE definition. Maybe Intel Compiler does auto-vectorization pretty well.

[john33]

Interesting, thanks.

[Anakunda]

Hello,
I've tried out new(todays) compiles of lame and the 64 bit version bug with not writing the encoder settings + corrupted version string is still here.
Are the developers not reading bugs reported in this thread? Please fix it.

[john33]

Hello,
I've tried out new(todays) compiles of lame and the 64 bit version bug with not writing the encoder settings + corrupted version string is still here.
Are the developers not reading bugs reported in this thread? Please fix it.

While I am not a lame-dev, I'm not sure I understand your problem. The following is from today's lame bundles, 32 bit and 64 bit:

CODE

Microsoft Windows [Version 6.1.7601]
Copyright © 2009 Microsoft Corporation. All rights reserved.

C:\Users\John>f:

F:\>cd testdir

F:\testdir>lame -V 2 14.wav 14.mp3
LAME 3.99.1 64bits (http://lame.sf.net)
CPU features: SSE (ASM used), SSE2 (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 14.wav to 14.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
14177/14177 (100%)| 0:09/ 0:09| 0:09/ 0:09| 39.989x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 5] %
80 [ 867] %%%%%%%%%%%%*
96 [ 1930] %%%%%%%%%%%%%%%%%%%%%%%%%%%*
112 [ 110] %%
128 [ 268] %***
160 [ 3274] %%%%%%%%%%%%%%%%%%%***************************
192 [ 4781] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
224 [ 1110] %%%%%%%%%%%*****
256 [ 1158] %%%%%%%%%%%******
320 [ 673] %%%%%%****
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
176.6 63.4 36.6 85.4 7.9 6.7
Writing LAME Tag...done
ReplayGain: 0.0dB

F:\testdir>lametag 14.mp3
LameTag - Reads the LAME tag from an mp3 file
Copyright © 2005 phwip
Release 0.4.1, compiled 2005-09-09

F:\testdir\14.mp3
Tag revision: 0
Encoder string: L3.9
Version string: 9r
Quality: 80 (V2 and q0)
Encoding method: vbr new / vbr mtrh
Lowpass: 18,500Hz
RG track peak: <not stored>
RG track gain: +0.0dB (determined automatically)
RG album gain: <not stored>
nspsytune: yes
nssafejoint: yes
nogap continued: no
nogap continuation: no
ATH type: 5
Bitrate: minimal (-b) bitrate 32
Encoder delay: 576 samples
Padded at end: 1,392 samples
Noise shaping: 1
Stereo mode: joint
Unwise settings: no
Source sample freq: 44.1kHz
MP3Gain change: <none>
Preset: V2: preset standard (fast mode)
Surround info: none
Music length: 8,166,730 bytes
Music CRC: 050C
Actual Music CRC: 050C
Info tag CRC: 10E8
Actual InfoTag CRC: 10E8


F:\testdir>lame -V 2 14.wav 14.mp3
LAME 3.99.1 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 14.wav to 14.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
14177/14177 (100%)| 0:11/ 0:11| 0:11/ 0:11| 32.794x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 2] %
80 [ 335] %%%%%
96 [ 2322] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*
112 [ 249] %%%%
128 [ 246] %***
160 [ 3240] %%%%%%%%%%%%%%%%%%****************************
192 [ 4798] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
224 [ 1147] %%%%%%%%%%%******
256 [ 1157] %%%%%%%%%%*******
320 [ 680] %%%%%%%***
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
177.7 63.4 36.6 85.4 7.9 6.7
Writing LAME Tag...done
ReplayGain: 0.0dB

F:\testdir>lametag 14.mp3
LameTag - Reads the LAME tag from an mp3 file
Copyright © 2005 phwip
Release 0.4.1, compiled 2005-09-09

F:\testdir\14.mp3
Tag revision: 0
Encoder string: L3.9
Version string: 9r
Quality: 80 (V2 and q0)
Encoding method: vbr new / vbr mtrh
Lowpass: 18,500Hz
RG track peak: <not stored>
RG track gain: +0.0dB (determined automatically)
RG album gain: <not stored>
nspsytune: yes
nssafejoint: yes
nogap continued: no
nogap continuation: no
ATH type: 5
Bitrate: minimal (-b) bitrate 32
Encoder delay: 576 samples
Padded at end: 1,392 samples
Noise shaping: 1
Stereo mode: joint
Unwise settings: no
Source sample freq: 44.1kHz
MP3Gain change: <none>
Preset: V2: preset standard (fast mode)
Surround info: none
Music length: 8,217,925 bytes
Music CRC: 0887
Actual Music CRC: 0887
Info tag CRC: 65E6
Actual InfoTag CRC: 65E6


F:\testdir>

The lame tag is essentially the same for both.

[JoeSyr]

Newbie question: what exactly do the libsndfile compiles offer that the others don't? I ask because I'd been using the normal compiles from rarewares to do FLAC->MP3 conversion in foobar2000 for a while, so seeing "This version of the libsndfile-1.dll provides FLAC and ogg vorbis (.ogg) input support." is confusing.

Is there any reason to not use the libsndfile version? And is it a feature of foobar that FLAC input is supported without it?

[john33]

Newbie question: what exactly do the libsndfile compiles offer that the others don't? I ask because I'd been using the normal compiles from rarewares to do FLAC->MP3 conversion in foobar2000 for a while, so seeing "This version of the libsndfile-1.dll provides FLAC and ogg vorbis (.ogg) input support." is confusing.

Is there any reason to not use the libsndfile version? And is it a feature of foobar that FLAC input is supported without it?

If you are doing the conversion via foobar2000, then there is no reason to change. foobar is taking care of the FLAC decoding for you. However, if you were attempting the conversion from the command line, then the standard compile would not work as it does not have the ability to accept FLAC input whereas the libsndfile version uses that library to perform the FLAC decoding, passing the decoded data to the lame encoder internally. I hope that's clear!

[Anakunda]

Hello,
I've tried out new(todays) compiles of lame and the 64 bit version bug with not writing the encoder settings + corrupted version string is still here.
Are the developers not reading bugs reported in this thread? Please fix it.

While I am not a lame-dev, I'm not sure I understand your problem. The following is from today's lame bundles, 32 bit and 64 bit:

CODE

Microsoft Windows [Version 6.1.7601]
Copyright © 2009 Microsoft Corporation. All rights reserved.

C:\Users\John>f:

F:\>cd testdir

F:\testdir>lame -V 2 14.wav 14.mp3
LAME 3.99.1 64bits (http://lame.sf.net)
CPU features: SSE (ASM used), SSE2 (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 14.wav to 14.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
14177/14177 (100%)| 0:09/ 0:09| 0:09/ 0:09| 39.989x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 5] %
80 [ 867] %%%%%%%%%%%%*
96 [ 1930] %%%%%%%%%%%%%%%%%%%%%%%%%%%*
112 [ 110] %%
128 [ 268] %***
160 [ 3274] %%%%%%%%%%%%%%%%%%%***************************
192 [ 4781] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
224 [ 1110] %%%%%%%%%%%*****
256 [ 1158] %%%%%%%%%%%******
320 [ 673] %%%%%%****
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
176.6 63.4 36.6 85.4 7.9 6.7
Writing LAME Tag...done
ReplayGain: 0.0dB

F:\testdir>lametag 14.mp3
LameTag - Reads the LAME tag from an mp3 file
Copyright © 2005 phwip
Release 0.4.1, compiled 2005-09-09

F:\testdir\14.mp3
Tag revision: 0
Encoder string: L3.9
Version string: 9r
Quality: 80 (V2 and q0)
Encoding method: vbr new / vbr mtrh
Lowpass: 18,500Hz
RG track peak: <not stored>
RG track gain: +0.0dB (determined automatically)
RG album gain: <not stored>
nspsytune: yes
nssafejoint: yes
nogap continued: no
nogap continuation: no
ATH type: 5
Bitrate: minimal (-b) bitrate 32
Encoder delay: 576 samples
Padded at end: 1,392 samples
Noise shaping: 1
Stereo mode: joint
Unwise settings: no
Source sample freq: 44.1kHz
MP3Gain change: <none>
Preset: V2: preset standard (fast mode)
Surround info: none
Music length: 8,166,730 bytes
Music CRC: 050C
Actual Music CRC: 050C
Info tag CRC: 10E8
Actual InfoTag CRC: 10E8


F:\testdir>lame -V 2 14.wav 14.mp3
LAME 3.99.1 32bits (http://lame.sf.net)
CPU features: MMX (ASM used), 3DNow! (ASM used), SSE (ASM used), SSE2
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding 14.wav to 14.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
14177/14177 (100%)| 0:11/ 0:11| 0:11/ 0:11| 32.794x| 0:00
32 [ 1] *
40 [ 0]
48 [ 0]
56 [ 0]
64 [ 2] %
80 [ 335] %%%%%
96 [ 2322] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*
112 [ 249] %%%%
128 [ 246] %***
160 [ 3240] %%%%%%%%%%%%%%%%%%****************************
192 [ 4798] %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%**************************
224 [ 1147] %%%%%%%%%%%******
256 [ 1157] %%%%%%%%%%*******
320 [ 680] %%%%%%%***
-------------------------------------------------------------------------------
kbps LR MS % long switch short %
177.7 63.4 36.6 85.4 7.9 6.7
Writing LAME Tag...done
ReplayGain: 0.0dB

F:\testdir>lametag 14.mp3
LameTag - Reads the LAME tag from an mp3 file
Copyright © 2005 phwip
Release 0.4.1, compiled 2005-09-09

F:\testdir\14.mp3
Tag revision: 0
Encoder string: L3.9
Version string: 9r
Quality: 80 (V2 and q0)
Encoding method: vbr new / vbr mtrh
Lowpass: 18,500Hz
RG track peak: <not stored>
RG track gain: +0.0dB (determined automatically)
RG album gain: <not stored>
nspsytune: yes
nssafejoint: yes
nogap continued: no
nogap continuation: no
ATH type: 5
Bitrate: minimal (-b) bitrate 32
Encoder delay: 576 samples
Padded at end: 1,392 samples
Noise shaping: 1
Stereo mode: joint
Unwise settings: no
Source sample freq: 44.1kHz
MP3Gain change: <none>
Preset: V2: preset standard (fast mode)
Surround info: none
Music length: 8,217,925 bytes
Music CRC: 0887
Actual Music CRC: 0887
Info tag CRC: 65E6
Actual InfoTag CRC: 65E6


F:\testdir>

The lame tag is essentially the same for both.

It's the metadata problem I reported yesterday. Look at the screenshot in Post #129.

Console dump with the corrupted metadata shown by MediaInfo here:

CODE

E:\xfer\download\music>lame --version
LAME 64bits version 3.99.1 (http://lame.sf.net)

Copyright (c) 1999-2011 by The LAME Project
Copyright (c) 1999,2000,2001 by Mark Taylor
Copyright (c) 1998 by Michael Cheng
Copyright (c) 1995,1996,1997 by Michael Hipp: mpglib

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Library General Public
License as published by the Free Software Foundation; either
version 2 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Library General Public License for more details.

You should have received a copy of the GNU Library General Public
License along with this program. If not, see
<http://www.gnu.org/licenses/>.

E:\xfer\download\music>lame -V 2 Show_Me_Your_Spine__Sample_.wav
LAME 3.99.1 64bits (http://lame.sf.net)
CPU features: SSE (ASM used), SSE2 (ASM used)
Using polyphase lowpass filter, transition band: 18671 Hz - 19205 Hz
Encoding Show_Me_Your_Spine__Sample_.wav to Show_Me_Your_Spine__Sample_.mp3
Encoding as 44.1 kHz j-stereo MPEG-1 Layer III VBR(q=2)
    Frame          |  CPU time/estim | REAL time/estim | play/CPU |    ETA
  1142/1142  (100%)|    0:02/    0:02|    0:02/    0:02|   13.824x|    0:00
32 [   0]
40 [   0]
48 [   0]
56 [   0]
64 [   0]
80 [   1] %
96 [   4] %
112 [   3] %
128 [   6] *
160 [ 451] %%%%%%**************************************************************
192 [ 344] %%%%%%**********************************************
224 [  79] %%%*********
256 [ 165] %%%%%%%******************
320 [  89] %%%%%*********
-------------------------------------------------------------------------------
   kbps        LR    MS  %     long switch short %
  199.8       14.8  85.2        68.1  17.4  14.4
Writing LAME Tag...done
ReplayGain: -4.3dB

E:\xfer\download\music>mediainfo Show_Me_Your_Spine__Sample_.mp3
General
Complete name                            : Show_Me_Your_Spine__Sample_.mp3
Format                                   : MPEG Audio
File size                                : 727 KiB
Duration                                 : 29s 831ms
Overall bit rate mode                    : Variable
Overall bit rate                         : 200 Kbps
Writing library                          : LAME3.99.1ŞŞŞŞŞŞŞŞŞŞ

Audio
Format                                   : MPEG Audio
Format version                           : Version 1
Format profile                           : Layer 3
Mode                                     : Joint stereo
Mode extension                           : MS Stereo
Duration                                 : 29s 831ms
Bit rate mode                            : Variable
Bit rate                                 : 200 Kbps
Channel(s)                               : 2 channels
Sampling rate                            : 44.1 KHz
Compression mode                         : Lossy
Stream size                              : 727 KiB (100%)
Writing library                          : LAME3.99.1ŞŞŞŞŞŞŞŞŞŞ


E:\xfer\download\music>

[robert]

Ok, I guess my other reply didn't make it clear.

Hello I still think there's some tagging bug in L3.99.1.
Especially it concerns writting encoder metadata to Lame header.
Convert anything with Lame 3.99.1 and look to metadata by MediaInfo or another metadata viewer.
Seems to me the encoder field is kinda corrupted. I get various results for the latest Lame build from Rarewarez.
On my test encode I got this:

Writing library : LAME3.99.1ŞŞŞŞŞŞŞŞŞŞ

This looks like the encoder doesnot zero terminate the encoder field properly, or even this value is written corrupted.
On another attempt the created mp3 even has no Lame version reported by MediaInfo.

This looks like a problem within MediaInfo. The field consists of 9 characters, no Zero termination required.

In foobar I always get this value:

Tool : L3.99r

which is kinda nonstandard too. Please fix it.

This is a correct value of the "encoder short version" field, but it should be ending with a patch level number after the "r".

[Anakunda]

This looks like a problem within MediaInfo. The field consists of 9 characters, no Zero termination required.

I'm using MediaInfo 0.7.50 official build. I wonder if that's MediaInfo problem as it shows version and encoder settings for all mp3s encoded with Lame 3.98.4 or older correctly.

[nao]

This is a correct value of the "encoder short version" field, but it should be ending with a patch level number after the "r".

Due to a small error in version.c, the patch level number is truncated in the release versions.

CODE

#define P "r";

should be

CODE

#define P "r"

to fix the issue.

[robert]

Thanks, nao. Fix committed to CVS main branch.

[john33]

Ho hum!!

I'll produce a new set of compiles with this fix, but it will likely not be until tomorrow now. Technically, it was a problem although I would imagine most are unconcerned by this, IMHO.

Always best to have things right, of course.

[JoeSyr]

Newbie question: what exactly do the libsndfile compiles offer that the others don't? I ask because I'd been using the normal compiles from rarewares to do FLAC->MP3 conversion in foobar2000 for a while, so seeing "This version of the libsndfile-1.dll provides FLAC and ogg vorbis (.ogg) input support." is confusing.

Is there any reason to not use the libsndfile version? And is it a feature of foobar that FLAC input is supported without it?

If you are doing the conversion via foobar2000, then there is no reason to change. foobar is taking care of the FLAC decoding for you. However, if you were attempting the conversion from the command line, then the standard compile would not work as it does not have the ability to accept FLAC input whereas the libsndfile version uses that library to perform the FLAC decoding, passing the decoded data to the lame encoder internally. I hope that's clear!

Crystal, thanks for clearing that up.

[DARcode]

Ok, I guess my other reply didn't make it clear.
[...]
This looks like a problem within MediaInfo. The field consists of 9 characters, no Zero termination required.

Not arguing, simply trying to understand: why the issue manifests itself with 3.99.1 and not 3.98.4 please?

[...]
I'll produce a new set of compiles with this fix, but it will likely not be until tomorrow now. Technically, it was a problem although I would imagine most are unconcerned by this, IMHO.

Which compiler settings then please? Is it not best you devs/coders first agree on the most compatible and hopefully best performing ones?