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: Problem Sample For Dibrom\'s Presets (Read 6056 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Problem Sample For Dibrom\'s Presets

I've been fooling around with Dibrom's new presets and have been very impressed that such high quality and versatility has been made available in mp3 encoding.  (Thanks Dibrom!)  I've been re-encoding some old CD's that I originally used the R3mix preset on but have since decided to encode in a higher quality manner.  I have had little in the way of problems until I started listening to mp3's made from my "Happy 2b Hardcore Chapter 4 " CD.  (The 4th incarnation in a set of 6 sweet CD's that should be part of every raver / electronic music fan's collection IMHO...)  Track 3 on the CD ("Better Day - GBT Inc.") has some funky sounding transients that sound a bit like fatboy, and when encoded with Dibrom's presets some strange things happen.

Here is the link to a clip from this song:
http://people.mw.mediaone.net/lklenk/music/gbtinc.pac


Here's a summary of what I’m hearing:

--alt-preset normal  :  Sounds pretty good, but there might be a bit of transient smearing and high-end degradation.  (I say might because I think I may hear a difference, but because I haven't had the time to properly ABX the sample, I don't want to draw any conclusions.)

--alt-preset high  : This sounds HORRIBLE!  It's a smeary awful mangled mess, and that's surprising because this preset is supposed to be higher quality than --alt-preset normal.

--alt-preset extreme  : Sounds similar to --alt-preset normal.

--alt-preset insane  : I can't tell any difference.

--alt-preset 192  (and up) : Sounds similar to --alt-preset normal 

--alt-preset 160  : There is some noticeable (though not horrible) smearing of transients.

--alt-preset 128  : I can barely listen to this, but it's not as bad as --alt-preset high

--r3mix  : VERY BAD... gives --alt-preset high a challenge for the worst sounding.


What I found interesting is that --alt-preset high sounds as bad as R3mix on these samples; however, I am told that Dibrom is working diligently on the problems with these "impulse" type sounds.  Also, I was pleasantly surprised by the quality of --alt-preset normal,  --alt-preset extreme,  and --alt-preset insane on this sample.  I have NEVER been able to make this song sound as good in mp3.

[Edit] : I changed the name of my post as well as some content to make things more clear.

[span style='font-size:9']Admin Note: attempting to change the title of this thread per MrDrew's request but having some problems...[/span]

Problem Sample For Dibrom\'s Presets

Reply #1 –
A cool sample for short block overkill! Only 72% here

As i heard, a fix is underway.

Wombat
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Problem Sample For Dibrom\'s Presets

Reply #2 –
First of all, I'll start off by saying that if this is an impulse sample, you are likely not going to get perfection with MP3 at any bitrate..

Now on the to rest..

Quote
Originally posted by MrDrew
Track 3 on the CD ("Better Day - GBT Inc.") has some funky sounding transients that sound a bit like fatboy, and when encoded with Dibrom's presets some strange things happen.

Here's a summary of what I’m hearing:

--alt-preset normal :  Sounds pretty good, but there might be a bit of smearing and shaky high end.  (I say might because i haven't ABX'ed yet, and I’ve learned not to trust the brain... lol)


Yeah its not 100% perfect, but it performs admirably well for the bitrate.  For comparison --r3mix sounds very bad on this sample.

Quote
--alt-preset high : This sounds HORRIBLE!  It's a smeary awful mangled mess, and that's surprising because this preset is supposed to be higher quality than --alt-preset normal.


I've stated a few times that --alt-preset high (which is the old dm-standard) doesn't handle impulses as well as the normal mode or the extreme mode.  I was planning on addressing this issue when I finished tweaking the normal mode, but due to some recent developments, the normal mode will probably replace this mode entirely.

Quote
--alt-preset extreme : Sounds similar to --alt-preset normal , except maybe a bit better.


It's close, but normal is actually better sounding due to some of the tweaks implemented in that mode which extreme doesn't have yet.

As for the rest..

Quote
--alt-preset 192 (and up) : Sounds similar to --alt-preset normal 

--alt-preset 160 : There is some noticeable (though not horrible) smearing of transients.

--alt-preset 128 : I can barely listen to this, but it's not as bad as --alt-preset high.

--alt-preset 112 (and lower) : UNLISTENABLE.


Of course on such a difficult sample, as you decrease bitrate, you are obviously going to lose quality.

In short, I wouldn't really say "Problem Sample for Dibrom's Presets", it'd be more correct to say "Problem Sample for MP3/LAME".  These kind of samples such as fatboy, short, ravebase, etc.. and this one.. all exploit the weaknesses of this particular format.  My presets, aside from the high, actually handle these cases rather well.. probably much better than most even.

Just wanted to add that to clear up any confusion.  I'm working on a few things which might increase quality on impulses some, but don't expect any miracles.  As it is, normal is nearly as good as it's going to get I think until perhaps temporal masking is implemented.

I do appreciate the sample btw though, but I added this comment so that none of this is taken out of context.  As I said I strive to make these samples sound good even though achieving perfection on them in LAME is pretty much impossible at the moment.

I suggest that if you are needing to encode a lot of music with these types of transients that you look at another format, such as MPC if you need absolute perfection.

Problem Sample For Dibrom\'s Presets

Reply #3 –
WOW!

What a killersample!!
Sounds really crap with mp3 
No problems at all with musepack

i love theese samples

Problem Sample For Dibrom\'s Presets

Reply #4 –
Dibrom,

Could you refesh my memory on what is temporal masking ™, briefly?

Is it that certain sounds very close in time to one another are not always perceptable?

Also is TM the devlopers are adding or do you know how to code it yourself???

Thanks.

Problem Sample For Dibrom\'s Presets

Reply #5 –
Dibrom, forgive my display of ignorance but isn't temporal masking already implemented in LAME?

Last time I checked the LAME source code (ok, it was few months ago) it had some hooks for simple temporal masking - maybe it is commented out now ...

Anyway - I think that it would be very hard to implement temporal masking in LAME (or in any other MP3 encoder implementation) because MDCT window length is too large for precise control over temporal masking parameters. You will end up either with too small masking (because of bound protection) or with too aggressive masking (because of large window size and post-echo smear)

Even with AAC, which has smaller windows, temporal masking is rather hard to control (my encoder has problems with some samples and therefore I left a command line switch to disable temporal masking)

Problem Sample For Dibrom\'s Presets

Reply #6 –
Hmm, Takehiro implemented some post-masking for Lame 3.88b for GPsycho. According to Robert, that is also used by nspsytune.

Pre-masking is usually considered to be too short in order to make sense implementing for mp3.

Temporal masking explained:
http://www-ccrma.stanford.edu/~bosse/proj/node21.html
Juha Laaksonheimo

Problem Sample For Dibrom\'s Presets

Reply #7 –
Quote
Originally posted by Ivan Dimkovic
Dibrom, forgive my display of ignorance but isn't temporal masking already implemented in LAME? 

Last time I checked the LAME source code (ok, it was few months ago) it had some hooks for simple temporal masking - maybe it is commented out now ...


To be strictly correct, there is temporal masking in LAME, but it is very simplistic and right now doesn't really do much of anything to help quality or bitrate.

Quote
Anyway - I think that it would be very hard to implement temporal masking in LAME (or in any other MP3 encoder implementation) because MDCT window length is too large for precise control over temporal masking parameters. You will end up either with too small masking (because of bound protection) or with too aggressive masking (because of large window size and post-echo smear)


Yes, this is very true.  I don't expect miracle to happen even if better temporal masking is added to LAME because of these very problems.  It would be hard to implement it to get around these issues.. however even a small improvement would be worth something I think.

Quote
Even with AAC, which has smaller windows, temporal masking is rather hard to control (my encoder has problems with some samples and therefore I left a command line switch to disable temporal masking)


Interesting, I wasn't aware of this.  I was under the impression that with AAC this would be easier, from out latest discussion on this topic.  Originally on an early thread in this board I didn't see how most transform coders could really take advantage of this aside from MPC because of them having a lower time resolution, but I believe you mentioned that AAC was able to use this on samples like fatboy which resulted in significant savings.  Naoki has also repeatedly said that he thinks temporal masking in LAME will help fatboy.  I'm not so sure about that actually, or how he plans on implementing better temporal masking in LAME, but I guess we'll just have to see..

Problem Sample For Dibrom\'s Presets

Reply #8 –
Yes, fatboy clip is coded transparently with significant savings in bitrate when temporal masking is used in AAC.

The problem of temporal masking in AAC is not directly related to short windows but to short window  grouping.

In AAC short blocks could be grouped in sections - ie.

2 4 1 1
3 2 2 1
4 1 1 2
8
1 1 1 1 1 1 1 1

All windows in one group share one scalefactor per band.

Sectioning is required because leaving all windows ungrouped would require very big side information (for scalefactors - 8x14 is rather large value) - however temporal masking is tricky with grouped windows, and it is very hard to control all that stuff together  But, if everything is implemented well it leads to very good sound

Problem Sample For Dibrom\'s Presets

Reply #9 –
Interesting addon:

I found RealJukebox V2 encode this clip surprisingly well with

Real Audio V8 at the default setting of 132kbit/s

and

Xing MP3 at 96 kbit/s.

Before you kill me for reason of blasphemy, try it yourself.

I listened with headphones very concentrated and I found it hard to notice a degradation of quality. The only thing I noticed is that the MP3 version lost some of its original stereo perception.

Before you accuse me of not being able to hear artifacts. I was the one posting the "killer sample for xing" on this forum. This sample, however, is definitely not a Xing killer.

Addendum: this sample causes a headache.

Problem Sample For Dibrom\'s Presets

Reply #10 –
Quote
Originally posted by cbuchner1
Interesting addon:

I found RealJukebox V2 encode this clip surprisingly well with

Real Audio V8 at the default setting of 132kbit/s

and 

Xing MP3 at 96 kbit/s.

Before you kill me for reason of blasphemy, try it yourself.


Alright.  I did, infact I even tried it at 112kbps with Xing.

Quote
I listened with headphones very concentrated and I found it hard to notice a degradation of quality. The only thing I noticed is that the MP3 version lost some of its original stereo perception.


What I noticed:

- Lots of smearing
- Post-echo all over
- Raspy and rattling sounds
- The tones lose all purity and sound very rough

Quote
Before you accuse me of not being able to hear artifacts. I was the one posting the "killer sample for xing" on this forum. This sample, however, is definitely not a Xing killer.


Think I'd have to disagree here.  This is not even remotely what I'd refer to as "high quality", let alone even the thought that this could be transparent.

Perhaps we have different ideas about quality, but this sample certainly doesn't sound good with Xing at all.

Problem Sample For Dibrom\'s Presets

Reply #11 –
Quote
Originally posted by Dibrom

Perhaps we have different ideas about quality, but this sample certainly doesn't sound good with Xing at all. 


I'd subscribe to that. I don't have trained and golden ears. The results were well within my "acceptability threshold".

Just one more thing. With what Xing version (build) did you try?

Problem Sample For Dibrom\'s Presets

Reply #12 –
Quote
Originally posted by cbuchner1
Just one more thing. With what Xing version (build) did you try?


Version 1.50 Build 9