IPB

Welcome Guest ( Log In | Register )

9 Pages V  « < 6 7 8 9 >  
Closed TopicStart new topic
lame 3.98.4, 3.99 alpha, 32- and 64-bit builds
shadowking
post Sep 14 2011, 11:35
Post #176





Group: Members
Posts: 1529
Joined: 31-January 04
Member No.: 11664



I dunno. Years ago i encoded with mpc -standard. In recent times I tried lame -V3. Very similar bitrate to mpc / nero 0.5 and you what: its not too bad at all. Most tracks are transparent with headphones or close to it. It doesn't have the annoying scfb21 issue , its VBR and unlike mpc , its compatible with nearly anything out there Mp3gain works on all hardware too. I guess i still really like efficiency .

So What i'm saying is that everything now is 250~300k. So why not just 256-320 CBR using lame from 2000 ? Its virtually the same. We have advanced so much yet ended up in the same place.

This post has been edited by shadowking: Sep 14 2011, 11:47


--------------------
Wavpack -b450s0.7
Go to the top of the page
+Quote Post
halb27
post Sep 14 2011, 18:29
Post #177





Group: Members
Posts: 2446
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



I came back to mp3 for the same reasons you've mentioned. And it's good enough for me.
Sure moderate bitrate users take better profit from Lame improvements. Whether or not that's essential is personal judgement.

This post has been edited by halb27: Sep 14 2011, 18:31


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
halb27
post Sep 14 2011, 18:58
Post #178





Group: Members
Posts: 2446
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (IgorC @ Sep 14 2011, 05:07) *
...
Sample14 (trumpet)

ABC/HR for Java, Version 0.53a, 12 September 2011
Testname:

Tester: IgorC

1L = sample14_3984_V0_2.wav
2R = sample14_399b0_V0_VNEW_3.wav
3L = sample14_397_V0_1.wav

Ratings on a scale from 1.0 to 5.0

---------------------------------------
General Comments:
---------------------------------------
1L File: sample14_3984_V0_2.wav
1L Rating: 3.6
1L Comment:
---------------------------------------
3L File: sample14_397_V0_1.wav
3L Rating: 4.3
3L Comment:
---------------------------------------

ABX Results:

3.98.4 has an artifact which was known as paper sound in past (?)

...

Oops, I didn't read carefully. Where's the result for 3.99? 3.97 -V0 better than 3.98.4 -V0 on trumpet? That can't be true. 3.97 had the sandpaper noise issue which 3.98 improved upon, and for 3.97 trumpet was a problem, whereas at least I am pretty content with 3.98.4 -V0 on it.

There must have gone something wrong.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
IgorC
post Sep 14 2011, 21:19
Post #179





Group: Members
Posts: 1581
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (halb27 @ Sep 14 2011, 14:58) *
That can't be true.

Different conditions: listener, hardware, room, time, mood and ... familiarity with sample and/or artifact (see below)

Also it's something related to it
http://www.hydrogenaudio.org/forums/index....st&p=743184

In other words You can perform the blind tests for some particular sample again and again during one day but it doesn't guarantee the same results if you will perform it next day/week. I think what really counts it is a tendency (many results) not particular one result.

QUOTE (halb27 @ Sep 14 2011, 14:58) *
Where's the result for 3.99?

It wasn't. The absense of the score in ABX log means 5.0. But as I said it _was_. Now I listened it the second time and alter the initial perception completely. The results have changed drastically. That's why I did quite a lot of samples (18 actually but didn't post them here) . It reveals the average tendency because most of all I care about average score. While there can be a statistical noise on single results.

This post has been edited by IgorC: Sep 14 2011, 21:26
Go to the top of the page
+Quote Post
halb27
post Sep 14 2011, 22:29
Post #180





Group: Members
Posts: 2446
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (IgorC @ Sep 14 2011, 22:19) *
...
Different conditions: listener, hardware, room, time, mood and ... familiarity with sample and/or artifact (see below)
...
The absense of the score in ABX log means 5.0. But as I said it _was_. Now I listened it the second time and alter the initial perception completely. The results have changed drastically. That's why I did quite a lot of samples (18 actually but didn't post them here) . It reveals the average tendency because most of all I care about average score. While there can be a statistical noise on single results.

I know the problem of different results with different tests very well. Ran upon it when testing lossyWav. It's annoying.
But in cases where I get totally different perceptions I'd rather not use the results. I'd only use results for those samples for which I can get perceptions which more or less reliably differentiate encoder versions.

If the a priori preferred encoder result of a sample is harder to ABX against the original (if in doubt because of equal or near-equal scores use the time it takes for ABXing as a measure for it) than is the alternative, this is kind of a confirmation for your initial perception. This is not foolproof of course, but it makes judgements on encoder results a little bit less personal.

As for my favorite mp3 problem sample trumpet I'd love to learn about your new results.

This post has been edited by halb27: Sep 14 2011, 23:04


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
IgorC
post Sep 15 2011, 06:02
Post #181





Group: Members
Posts: 1581
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (halb27 @ Sep 14 2011, 18:29) *
As for my favorite mp3 problem sample trumpet I'd love to learn about your new results.

I have no problem to provide the results. The problem is that they are variable.
During the day I have made 5 times the same trumpet sample. Now 3.98.4 was the best. All 5 times it was 3.98.4>3.97>3.99b0. When I got back home at night and made the same test twice and twice time it was 3.98.4>3.99b0>3.97.


Possible explanation is the the conditions of the test have changed.
During the day the level of noise was quite high at home (cars). The night was quite.

For now it's the last time for me I test trumpet sample. dry.gif I remember I have the same experience with sample Take Your Finger From My Head.

P.S. Additional comparison codec A vs codec B (besides of codec A vs lossless, codec B vs lossless) doesn't help for these samples.
http://www.hydrogenaudio.org/forums/index....st&p=743197

This post has been edited by IgorC: Sep 15 2011, 06:13
Go to the top of the page
+Quote Post
halb27
post Sep 15 2011, 06:36
Post #182





Group: Members
Posts: 2446
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



Thanks a lot for your efforts.
As far as 3.98.4 is concerned your overall results on trumpet agree with mine (definitely compared to 3.97, but I can't talk about 3.99b0 which I have no experience with, just with early alpha versions with which I could not hear an improvement on trumpet).

This post has been edited by halb27: Sep 15 2011, 06:54


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
IgorC
post Sep 15 2011, 06:58
Post #183





Group: Members
Posts: 1581
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



Thank You too for bringing this out.
It makes me remember of the previous issues and re-think, improve some technics.
Go to the top of the page
+Quote Post
DigitalDictator
post Sep 15 2011, 12:52
Post #184





Group: Members
Posts: 313
Joined: 9-August 02
From: SoFo
Member No.: 3002



QUOTE (IgorC @ Sep 15 2011, 07:02) *
QUOTE (halb27 @ Sep 14 2011, 18:29) *
As for my favorite mp3 problem sample trumpet I'd love to learn about your new results.

I have no problem to provide the results. The problem is that they are variable.
During the day I have made 5 times the same trumpet sample. Now 3.98.4 was the best. All 5 times it was 3.98.4>3.97>3.99b0. When I got back home at night and made the same test twice and twice time it was 3.98.4>3.99b0>3.97.


Possible explanation is the the conditions of the test have changed.
During the day the level of noise was quite high at home (cars). The night was quite.

For now it's the last time for me I test trumpet sample. dry.gif I remember I have the same experience with sample Take Your Finger From My Head.

P.S. Additional comparison codec A vs codec B (besides of codec A vs lossless, codec B vs lossless) doesn't help for these samples.
http://www.hydrogenaudio.org/forums/index....st&p=743197

I've been meaning to ask about this "phenomenon" before. Does this indicate that, for example, the last public test @96 kbps would come out differently if the same people did the tests a second time? I mean, if the artifacts are so subtle and it has a lot to do with your own personal state of mind (eg. tired, bored, stressed out etc.), the outcome is mererly a result of the testers' shape that day, and not so much the encoder itself? Just a thought...
Go to the top of the page
+Quote Post
halb27
post Sep 15 2011, 15:48
Post #185





Group: Members
Posts: 2446
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



The outcome can change, but as there are many testers who contributed to the listening test, I can't imagine things would change significantly.
The exact numerical outcome shouldn't be taken too serious anyway, and the confidence intervals should be respected.

The main outcome of the test can be trusted IMO which is:
- Apple Quicktime is better than Nero
- Apple Quicktime TVBR is not better than CVBR
- new FhG encoder is in the quality range of Apple Quicktime
- CT encoder is between Apple Quicktime and Nero qualitywise
- looking at the outcome of the individual samples there is no significant deviation of relative encoder quality from the average outcome over all the samples.
  As a consequence looking at the average result is sufficient for comparing encoder quality (with the last mp3@128 kbps test it was a different story).
- at least for the better encoders quality is very high for 96 kbps encodings - with sample 3 being an exception to this.

This post has been edited by halb27: Sep 15 2011, 16:02


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
IgorC
post Sep 15 2011, 20:07
Post #186





Group: Members
Posts: 1581
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



QUOTE (DigitalDictator @ Sep 15 2011, 08:52) *
Does this indicate that, for example, the last public test @96 kbps would come out differently if the same people did the tests a second time?

No, it wouldn't be different at all. This phenomenon is canceled between different results of the listeners. It will be already canceled on large number of the samples for the same listener.
Testing AAC at 96 kbps isn't the same thing as testing LAME V0 (far from that). The correlation between the average results and results of particular listener was quite high (70%).

Also this phenomenon doesn't happen for each sample and listener.

This post has been edited by IgorC: Sep 15 2011, 20:14
Go to the top of the page
+Quote Post
john33
post Sep 28 2011, 22:35
Post #187


xcLame and OggDropXPd Developer


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



3.99beta1 x86 and x64 compiles now at Rarewares. smile.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Fishman0919
post Sep 30 2011, 04:35
Post #188





Group: Members
Posts: 79
Joined: 18-December 03
Member No.: 10554



WOOT
Go to the top of the page
+Quote Post
viktor
post Sep 30 2011, 09:53
Post #189





Group: Members
Posts: 302
Joined: 17-November 06
Member No.: 37682



QUOTE (john33 @ Sep 28 2011, 23:35) *
3.99beta1 x86 and x64 compiles now at Rarewares. smile.gif


interesting results:

- 3.98.4 x86: 4:20
- 3.98.4 x64: 4:32
- 3.99b1 x86: 6:06
- 3.99b1 x64: 3:15

on the same sample with default settings.
Go to the top of the page
+Quote Post
lvqcl
post Sep 30 2011, 17:52
Post #190





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



Maybe 32-bit version was compiled with optimizations for Intel processors only.
Go to the top of the page
+Quote Post
viktor
post Sep 30 2011, 23:53
Post #191





Group: Members
Posts: 302
Joined: 17-November 06
Member No.: 37682



QUOTE (lvqcl @ Sep 30 2011, 18:52) *
Maybe 32-bit version was compiled with optimizations for Intel processors only.


maybe, but only the beta one?
Go to the top of the page
+Quote Post
robert
post Oct 3 2011, 10:17
Post #192


LAME developer


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



John, there is something very odd with your x86-32 build, it's way too slow.
Just for comparison, mine compiled with VC9 Express edition (32 bits, haven't figured out how to set it up for x86-64 builds), running on AMD Athlon 64 X2, Win7-64:

Debug: 51
Release: 19
NASM: 17
SSE2: 14

now John's (Intel?) builds:
x86-32: 22
x86-64: 12

Go to the top of the page
+Quote Post
john33
post Oct 3 2011, 11:48
Post #193


xcLame and OggDropXPd Developer


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



Robert, having just tested the 32bit compile on a 1075T, hex core @3.6, it runs at about half the speed of the 64 bit compile, which is bizarre to say the least! I can't immediately think of anything that may be responsible, but I'll look into it and report back.

This post has been edited by db1989: Oct 3 2011, 17:23
Reason for edit: deleting pointless full quote of last post


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
john33
post Oct 3 2011, 16:11
Post #194


xcLame and OggDropXPd Developer


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



OK, having recompiled using VS2008, not Intel, it would seem that this is the Intel screwing AMD issue! Here are two compiles x86 and x64, both non-Intel that I would like to be tested please:

x86 - http://homepage.ntlworld.com/jfe1205/LAME/lame3.99.b1_1.zip

x64 - http://homepage.ntlworld.com/jfe1205/LAME/....99.b1-64_1.zip

The testing I have done suggests that the speed of these is very little different on Intel CPUs to what it was using the Intel compiler. However, on AMD (I only have the hex core 1075T to test on) the x64 compile is around the same speed as before, but the x86 compile is around 50% faster.

I'd be interested in other peoples experiences and any other comments. smile.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Alex B
post Oct 3 2011, 18:49
Post #195





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



A quad-core AMD Phenom II, XP Pro 32-bit, foobar2000, four simultaneous encoding processes, -S -V2 --noreplaygain - %d, source: 25 various wave tracks.

3.99b1 (x86)
Total encoding time: 1:23.719, 65.66x realtime

3.99b1_1 (x86)
Total encoding time: 0:53.688, 102.40x realtime

3.98.4 (the main bundle from Rarewares)
Total encoding time: 0:40.922, 134.34x realtime

3.98.4 (the VC6 compile from Rarewares)
Total encoding time: 0:41.625, 132.07x realtime


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
john33
post Oct 3 2011, 21:55
Post #196


xcLame and OggDropXPd Developer


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



New Intel compiles with the 'icc-patcher' applied to both compiles. Seems to have no effect on running on Intel CPUs, but improves AMD CPU performance.

x86 - http://homepage.ntlworld.com/jfe1205/LAME/lame3.99.b1_1.zip

x64 - http://homepage.ntlworld.com/jfe1205/LAME/....99.b1-64_1.zip

Comments, etc., would be appreciated. smile.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
robert
post Oct 4 2011, 09:07
Post #197


LAME developer


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



Your new Intel compiles seem OK, the x64-32 improved from 22 to 15 seconds in the same test as before.
I couldn't test your VS2008 ones, I was too late to the party, as you already replaced them with the IC ones. wink.gif
Thanks John.
Go to the top of the page
+Quote Post
john33
post Oct 4 2011, 09:54
Post #198


xcLame and OggDropXPd Developer


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



Thanks guys, I'll replace the compiles on Rarewares with these. smile.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post
Alex B
post Oct 4 2011, 11:09
Post #199





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



The 'icc-patcher' compile (x86):
Total encoding time: 0:51.359, 107.04x realtime

It is slightly faster than the VS2008 compile. 3.98.4 is still quite a bit faster, but perhaps that is caused by the differences in the encoders.

I don't have a 64-bit OS installed so I can't compare the x86 and x64 versions.


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
john33
post Oct 4 2011, 11:37
Post #200


xcLame and OggDropXPd Developer


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



Thanks, Alex. I have the opposite problem, all my systems are now running Windows 7 x64! wink.gif


--------------------
John
----------------------------------------------------------------
My compiles and utilities are at http://www.rarewares.org/
Go to the top of the page
+Quote Post

9 Pages V  « < 6 7 8 9 >
Closed 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: 26th December 2014 - 01:30