dBpower LAME 320 CBR - "fast" encode fewer artifacts - why? Options

[superbu]

I'm not sure if this is in the proper forum, although I did do ABX listening tests, which I'll post below. But all the first one shows it that two different 320kb LAME encodes were ABX-able.

At any rate, I can't figure something out: While comparing 320kb LAME encodes of the popular killer sample "Show Me Your Spine," encoded using dBpoweramp, I found that the well-known "sandpaper scratching" artifact that is prominent in the first few seconds of the song was much more noticeable when I selected "Slow (High Quality)" than when I selected "Fast (Low Quality)." To my ears, the "Fast (Low Quality)" setting produced a result much closer to transparency (though definitely NOT transparent), while with the "Slow (High Quality)" setting the artifacts were VERY obvious.

I can't prove this other than to post the results of comparing those two compressed samples, where I scored 12/12 in differentiating them. There was a faint "cripsy" artifact at a particular point in the "slow" encode that was not present in the "fast" encode, and I'm also hearing that "scratching" sound more prominently in the Slow encode. Again, I scored 12/12:

foo_abx 1.3.4 report
foobar2000 v1.1.2
2011/11/21 00:56:55

File A: L:\Music Folder\1 MP3 Files for flash drive\Show_Me_Your_Spine__Sample (dB 320 quality fast).mp3
File B: L:\Music Folder\1 MP3 Files for flash drive\Show_Me_Your_Spine__Sample (dB 320 quality slow).mp3

00:56:55 : Test started.
00:59:27 : 01/01 50.0%
01:02:12 : 02/02 25.0%
01:04:19 : 03/03 12.5%
01:05:31 : 04/04 6.3%
01:07:33 : 05/05 3.1%
01:08:38 : 06/06 1.6%
01:09:28 : 07/07 0.8%
01:10:02 : 08/08 0.4%
01:10:46 : 09/09 0.2%
01:11:23 : 10/10 0.1%
01:12:09 : 11/11 0.0%
01:12:55 : 12/12 0.0%
01:12:59 : Test finished.

----------
Total: 12/12 (0.0%)

Since I could also ABX the "fast" version 11/11 times with the original WAV, I didn't bother to ABX the "slow" encode with the WAV:

foo_abx 1.3.4 report
foobar2000 v1.1.2
2011/11/21 01:18:16

File A: C:\Users\superbu\Music\1 WAV Files For Itunes Import\Show_Me_Your_Spine__Sample (TRUE WAV).wav
File B: L:\Music Folder Backup\1 MP3 Files for flash drive\Show_Me_Your_Spine__Sample (db 320 quality fast).mp3

01:18:16 : Test started.
01:19:37 : 01/01 50.0%
01:20:24 : 02/02 25.0%
01:21:04 : 03/03 12.5%
01:21:36 : 04/04 6.3%
01:22:11 : 05/05 3.1%
01:23:00 : 06/06 1.6%
01:23:27 : 07/07 0.8%
01:24:33 : 08/08 0.4%
01:25:35 : 09/09 0.2%
01:26:04 : 10/10 0.1%
01:26:47 : 11/11 0.0%
01:26:52 : Test finished.

----------
Total: 11/11 (0.0%)

Anyway, can someone explain to me how it's possible that the "fast (low quality)" encode could have less prominent artifacts than the "slow (high quality)" encode? I thought the slow encode was supposed to be of better quality.

This post has been edited by superbu: Nov 22 2011, 05:12

[db1989]

It certainly may help to upload your samples (30 seconds or shorter) for others to try.

I do recall reading that quality settings above the default, such as those invoked by -h or by numerically lower -q levels may actually lessen quality; I’ll leave this question to someone with more recent experience and knowledge.

[superbu]

It certainly may help to upload your samples (30 seconds or shorter) for others to try.

I do recall reading that quality settings above the default, such as those invoked by -h or by numerically lower -q levels may actually lessen quality; I’ll leave this question to someone with more recent experience and knowledge.

Good idea. Here is the link to the thread with the samples:

http://www.hydrogenaudio.org/forums/index....showtopic=91968

[lvqcl]

It seems that fast / slow means -f / -h (IOW: fast/normal/slow = -q7/-q3/-q2).

[psycho]

I do recall reading that quality settings above the default, such as those invoked by -h or by numerically lower -q levels may actually lessen quality;

I just want to say that I also have memorized this to be true. But I can't remember, where I read about it.

[lvqcl]

An example: http://www.hydrogenaudio.org/forums/index....showtopic=83820

[db1989]

To keep discussion in this thread, I’ll reply to your post from Uploads here:

Apparently too late to edit the above post

Yes, editing is only available for an hour after posting, for various reasons. I amended your initial post just in case.

I meant to say that the Foobar "Show Me Your Spine" samples sounded WORSE than the dBpoweramp encodes. Not sure why that is -- both use LAME 3.98, but the Foobar encodes actually sounded worse than even the "Fast (High Quality)" setting on dBpoweramp.

Were exactly identical encoders and settings used in both foobar2000 and dBpowerAMP? You’re right to be baffled if so! But again, I think more information will be needed before anyone can propose an explanation for either of the phenomena that you’ve described. Perhaps another pair of samples, this time created by foobar2000 and dBpowerAMP respectively? Assuming, that is, that you verify the setup as noted above.

[smok3]

and you did actually abx all this? Care to share some abx logs?

[superbu]

To keep discussion in this thread, I’ll reply to your post from Uploads here:

Apparently too late to edit the above post

Yes, editing is only available for an hour after posting, for various reasons. I amended your initial post just in case.

I meant to say that the Foobar "Show Me Your Spine" samples sounded WORSE than the dBpoweramp encodes. Not sure why that is -- both use LAME 3.98, but the Foobar encodes actually sounded worse than even the "Fast (High Quality)" setting on dBpoweramp.

Were exactly identical encoders and settings used in both foobar2000 and dBpowerAMP? You’re right to be baffled if so! But again, I think more information will be needed before anyone can propose an explanation for either of the phenomena that you’ve described. Perhaps another pair of samples, this time created by foobar2000 and dBpowerAMP respectively? Assuming, that is, that you verify the setup as noted above.

Good point, db1989. Unless they are using the exact same version of LAME with the exact same settings, it's not fair to compare them. I really mentioned it only as an aside.

I'm mainly concerned with why the high quality setting on dBpoweramp's LAME at 320kb produces more artifacts in the "Show Me Your Spine" sample than than the low quality setting does, particularly since with dBpoweramp you must select a quality setting -- fast (low), normal (medium), or slow (high).

[superbu]

and you did actually abx all this? Care to share some abx logs?

You mean ABX Foobar vs. dBpoweramp? No. I could, but as db1989 pointed out, unless I can verify that the two encoders were using identical versions of LAME with identical settings, it would prove nothing.

This post has been edited by superbu: Nov 27 2011, 10:00

[db1989]

I'm mainly concerned with why the high quality setting on dBpoweramp's LAME at 320kb produces more artifacts in the "Show Me Your Spine" sample than than the low quality setting does, particularly since with dBpoweramp you must select a quality setting -- fast (low), normal (medium), or slow (high).

It’s a completely fair question, but again the existence of this phenomenon has been known for a while and discussed at various points. Unfortunately, though, I don’t know of any specific threads/posts to point you to (besides that given by lvqcl, of course). Perhaps someone who has been paying more technical attention to LAME—maybe even a developer—could weigh in.

I’m also interested to know whether or not this issue has propagated to version 3.99 (it’s not something I could easily test myself at the moment).

[superbu]

I’m also interested to know whether or not this issue has propagated to version 3.99 (it’s not something I could easily test myself at the moment).

It has. I set the CLI encoder on dBpoweramp to use 3.99.2 (which has not yet been integrated into dBpoweramp), and the issue is definitely still there. I can post ABX comparisons in the next day or two.

What's interesting is that the point at which the artifacts on "Show Me Your Spine" get significantly harder to hear is at Q7... which is apparently where LAME stops using noise shaping:

http://lame.cvs.sourceforge.net/viewvc/lam...detailed.html#q

For CBR, ABR and --vbr-old modes, the following table applies
-q 0 Use slowest & best possible version of all algorithms.
-q 3 Default value. Good speed, good quality
-q 7 Very fast, ok quality. (psycho acoustics are used for pre-echo & M/S, but no noise shaping is done.
-q 9 Disables almost all algorithms including psy-model. Poor quality.

Could be a coincidence, though. I appreciate all the comments and links. I guess for now I'll just encode everything at Q7.

This post has been edited by superbu: Nov 29 2011, 09:31

[db1989]

I doubt that is a good idea. The default quality setting is such for a reason. Why use a lower value and thus risk degrading quality on a large number of tracks simply because you have found one track for which low quality settings remove one type of artefact?

[superbu]

I doubt that is a good idea. The default quality setting is such for a reason. Why use a lower value and thus risk degrading quality on a large number of tracks simply because you have found one track for which low quality settings remove one type of artefact?

I suppose you're right.

[Martel]

I clearly recall there was some version of LAME many years ago where setting q=0 resulted in a clearly inferior encoding. I remember I was very surprised by that myself. Unfortunately, I don't recall which version it was (3.96/3.97?) but I haven't used the switch ever since.