Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: dBpower LAME 320 CBR - "fast" encode fewer artifacts - why? (Read 9688 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

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

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.

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

Reply #1
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.

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

Reply #2
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

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

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

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

Reply #4
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.
lame -V 0


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

Reply #6
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.

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

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

Reply #7
and you did actually abx all this? Care to share some abx logs?
PANIC: CPU 1: Cache Error (unrecoverable - dcache data) Eframe = 0x90000000208cf3b8
NOTICE - cpu 0 didn't dump TLB, may be hung

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

Reply #8
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.

Quote
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).

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

Reply #9
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.

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

Reply #10
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).

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

Reply #11
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

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

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

Reply #12
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?

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

Reply #13
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.

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

Reply #14
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.