IPB

Welcome Guest ( Log In | Register )

16 Pages V  « < 4 5 6 7 8 > »   
Reply to this topicStart new topic
LAME 3.99 is out, 2012-02-28: version 3.99.5 has been released
Broadway
post Nov 8 2011, 18:52
Post #126





Group: Members
Posts: 9
Joined: 6-November 11
Member No.: 95000



QUOTE (john33 @ Nov 8 2011, 15:54) *
Revised version which includes the extended VRB Quality range is here for testing, if those who are interested would be so kind. smile.gif

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!
Go to the top of the page
+Quote Post
john33
post Nov 8 2011, 18:56
Post #127


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (Broadway @ Nov 8 2011, 18:52) *
QUOTE (john33 @ Nov 8 2011, 15:54) *
Revised version which includes the extended VRB Quality range is here for testing, if those who are interested would be so kind. smile.gif

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. smile.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Broadway
post Nov 9 2011, 16:29
Post #128





Group: Members
Posts: 9
Joined: 6-November 11
Member No.: 95000



QUOTE (john33 @ Nov 8 2011, 18:56) *
...
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!
smile.gif
Go to the top of the page
+Quote Post
Anakunda
post Nov 9 2011, 16:36
Post #129





Group: Members
Posts: 450
Joined: 24-November 08
Member No.: 63072



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
Go to the top of the page
+Quote Post
lock67ca
post Nov 9 2011, 16:52
Post #130





Group: Members
Posts: 25
Joined: 24-June 05
Member No.: 22928



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
Go to the top of the page
+Quote Post
Anakunda
post Nov 9 2011, 16:57
Post #131





Group: Members
Posts: 450
Joined: 24-November 08
Member No.: 63072



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Ş“‘dFĄĽ;Ň

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
Go to the top of the page
+Quote Post
Wombat
post Nov 9 2011, 17:21
Post #132





Group: Members
Posts: 977
Joined: 7-October 01
Member No.: 235



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."

Go to the top of the page
+Quote Post
john33
post Nov 9 2011, 17:36
Post #133


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



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

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.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
robert
post Nov 9 2011, 17:51
Post #134


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



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
Go to the top of the page
+Quote Post
lvqcl
post Nov 9 2011, 17:56
Post #135





Group: Developer
Posts: 3325
Joined: 2-December 07
Member No.: 49183



john33, please compile NASM version with SSE enabled and fast FP (/arch:SSE /fp:fast). I suspect that it will be faster than now.
Go to the top of the page
+Quote Post
john33
post Nov 9 2011, 18:19
Post #136


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (lvqcl @ Nov 9 2011, 17:56) *
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!


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
nao
post Nov 9 2011, 18:57
Post #137





Group: Members
Posts: 86
Joined: 16-June 06
Member No.: 31911



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.
Go to the top of the page
+Quote Post
john33
post Nov 9 2011, 19:11
Post #138


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



Interesting, thanks. smile.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Anakunda
post Nov 10 2011, 19:00
Post #139





Group: Members
Posts: 450
Joined: 24-November 08
Member No.: 63072



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.
Go to the top of the page
+Quote Post
john33
post Nov 10 2011, 19:22
Post #140


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (Anakunda @ Nov 10 2011, 19:00) *
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.


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
JoeSyr
post Nov 10 2011, 19:28
Post #141





Group: Members
Posts: 18
Joined: 8-May 11
Member No.: 90460



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?
Go to the top of the page
+Quote Post
john33
post Nov 10 2011, 19:37
Post #142


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



QUOTE (JoeSyr @ Nov 10 2011, 19:28) *
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! wink.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Anakunda
post Nov 10 2011, 19:38
Post #143





Group: Members
Posts: 450
Joined: 24-November 08
Member No.: 63072



QUOTE (john33 @ Nov 10 2011, 19:22) *
QUOTE (Anakunda @ Nov 10 2011, 19:00) *
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>
Go to the top of the page
+Quote Post
robert
post Nov 10 2011, 19:38
Post #144


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



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

QUOTE (Anakunda @ Nov 9 2011, 16:36) *
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.

QUOTE
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".
Go to the top of the page
+Quote Post
Anakunda
post Nov 10 2011, 19:41
Post #145





Group: Members
Posts: 450
Joined: 24-November 08
Member No.: 63072



QUOTE (robert @ Nov 10 2011, 19:38) *
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.
Go to the top of the page
+Quote Post
nao
post Nov 10 2011, 19:45
Post #146





Group: Members
Posts: 86
Joined: 16-June 06
Member No.: 31911



QUOTE (robert @ Nov 11 2011, 03:38) *
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.
Go to the top of the page
+Quote Post
robert
post Nov 10 2011, 19:48
Post #147


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



Thanks, nao. Fix committed to CVS main branch.
Go to the top of the page
+Quote Post
john33
post Nov 10 2011, 20:07
Post #148


xcLame and OggDropXPd Developer


Group: Developer
Posts: 3760
Joined: 30-September 01
From: Bracknell, UK
Member No.: 111



Ho hum!! wink.gif

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. smile.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
JoeSyr
post Nov 10 2011, 21:12
Post #149





Group: Members
Posts: 18
Joined: 8-May 11
Member No.: 90460



QUOTE (john33 @ Nov 10 2011, 13:37) *
QUOTE (JoeSyr @ Nov 10 2011, 19:28) *
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! wink.gif


Crystal, thanks for clearing that up.
Go to the top of the page
+Quote Post
DARcode
post Nov 11 2011, 10:34
Post #150





Group: Members (Donating)
Posts: 681
Joined: 10-January 05
From: Italy
Member No.: 18968



QUOTE (robert @ Nov 10 2011, 19:38) *
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?

QUOTE (john33 @ Nov 10 2011, 20:07) *
[...]
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?


--------------------
WavPack 4.70.0 -b384hx6cmv/qaac 2.41 -V 100
Go to the top of the page
+Quote Post

16 Pages V  « < 4 5 6 7 8 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th July 2014 - 10:42