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: Possible MPC problem (Was: Crap MPC!) (Read 6426 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Possible MPC problem (Was: Crap MPC!)

Argh.. It appears that MTRH deleted his post (which was the first post) in the thread "Crap MPC!" and there was an option set which I could have sworn I turned off, which let users who had the first post in a thread, delete the entire thing if they deleted their post.  I am very, very sorry to all who posted in that thread.  It was a serious oversight on my part (I'm still a little new to vB) but I have taken steps to prevent this from happening in the future.  Fortunately, JohnV had the entire thread in his cache, so I can at least post a link to the information that was in the thread.  You can read the cached thread in question here:

http://www.hydrogenaudio.org/oldthread/showthread.php

Again, I sincerely apologize for this inconvenience.

Please post any responses to that old thread in this one.

Possible MPC problem (Was: Crap MPC!)

Reply #1 –
Heh, ok let's continue. So, waiting for layer3maniac's test sample.

upload to ff123's ftp:

ftp.ff123.net/incoming
login:  [a href='mailto:anonymous@ff123.net'][/a]
(leave password blank)
Juha Laaksonheimo

Possible MPC problem (Was: Crap MPC!)

Reply #2 –
Wouldn't it be possible for MPC to increase to nmt automatically when it detects a very noise-like signal like a cymbal or a hihat?

Or is this in itself the problem i.e. detecting what is the instrument and what is noise doesn't work. In that case for hihats maybe the same kind of trigger that is used for mp3/ogg/acc block switching can be applied, but not for the transient itself, but for the noise part thereafter. (My Ogg mode drops the noise masking on the transient itself)

If you need a hihat clip that isn't transparent, try the AQ test clip from Roel. I can ABX it on all presets.

--
GCP

Possible MPC problem (Was: Crap MPC!)

Reply #3 –
Quote
Originally posted by Garf
Wouldn't it be possible for MPC to increase to nmt automatically when it detects a very noise-like signal like a cymbal or a hihat?

Or is this in itself the problem i.e. detecting what is the instrument and what is noise doesn't work. In that case for hihats maybe the same kind of trigger that is used for mp3/ogg/acc block switching can be applied, but not for the transient itself, but for the noise part thereafter. (My Ogg mode drops the noise masking on the transient itself)


Apparently, yes, it is an issue of tonality estimation.  I've heard that Buschel is planning on reworking some of this in the future though I am not sure about it.  For that matter though another feature, CVD, does actually dynamically change around the NMT but I'm not quite sure how it would apply in this case.  I think that somehow something like what you mentioned IS done though, especially considering the fact that MPC scales to very high bitrates on clips with some insane transients.

Quote
If you need a hihat clip that isn't transparent, try the AQ test clip from Roel. I can ABX it on all presets.


Just to be clear, are we talking about the non lowpassed version here?  If not, I think lowpassing could be the issue.  Then again, it is possible that hihat would not be transparent, though this is a synthetic hihat which is quite different than what you are going to hear in rock.  Oddly enough, synthetic hihats and other drums seem to give other codecs the most problems.  It would be interesting to see how vorbis and aac faired on that clip.

Possible MPC problem (Was: Crap MPC!)

Reply #4 –
Well, I don't want to leave my anonymous FTP writable indefinitely -- I might forget to check it to make sure somebody doesn't start using it as a dropoff point for cool warez.  If somebody wants to upload stuff, I can always reopen it.

ff123

Possible MPC problem (Was: Crap MPC!)

Reply #5 –
Quote
Originally posted by Dibrom

Just to be clear, are we talking about the non lowpassed version here?


Yes. If I encode the original clip with -standard, -xtreme or -insane I can ABX the encode from the original. It does get better on -xtreme and -insane, but not enough.

--
GCP

Possible MPC problem (Was: Crap MPC!)

Reply #6 –
Perhaps Buschel can take a look at this then.  As far as I know this is one of the very few clips MPC might have problems with, and I believe it is probably unrelated to "problem" here.  Supported by the fact that original poster said he only made the post to tease JMK (and later deleted it) and that the other person mentioning "problems" looks as if they are not going to be uploading a clip after all.

Possible MPC problem (Was: Crap MPC!)

Reply #7 –
Quote
Originally posted by Dibrom
Perhaps Buschel can take a look at this then.  As far as I know this is one of the very few clips MPC might have problems with, and I believe it is probably unrelated to "problem" here.  Supported by the fact that original poster said he only made the post to tease JMK (and later deleted it) and that the other person mentioning "problems" looks as if they are not going to be uploading a clip after all.


Well, I suppose you have that AQ clip still lying around somewhere.

Here are my results on my own encode of the original:

-standard:

[...]
Listening  X    Vote for X:=A  OK    21/33    6.14418  0.08 bit           
Listening  X    Vote for X:=B  OK    22/34    8.23388  0.09 bit           
Listening  X    Vote for X:=B  OK    23/35    11.1693  0.10 bit           
Listening  X    Vote for X:=A  OK    24/36    15.3268  0.11 bit           
Listening  X    Vote for X:=B  OK    25/37    21.2626  0.12 bit           
Listening  X    Vote for X:=A  OK    26/38    29.8041  0.13 bit           
Listening  X    Vote for X:=B  OK    27/39    42.1893  0.14 bit           
Listening  X    Vote for X:=A  OK    28/40    60.2809  0.15 bit           
Listening  X    Vote for X:=B  OK    29/41    86.8977  0.16 bit           
Listening  X    Vote for X:=B  OK    30/42    126.328  0.17 bit           
Listening  X    Vote for X:=A  OK    31/43    185.131  0.17 bit           
Listening  X    Vote for X:=B  OK    32/44    273.391  0.18 bit           
Listening  X    Vote for X:=A  OK    33/45    406.686  0.19 bit           
Listening  X    Vote for X:=B  OK    34/46    609.202  0.20 bit           
Listening  X    Vote for X:=B  OK    35/47    918.663  0.21 bit           
Listening  X    Vote for X:=B  OK    36/48    1394.18  0.22 bit           
Listening  X    Vote for X:=A  OK    37/49    2128.76  0.23 bit           
Listening  X    Vote for X:=A  OK    38/50    3269.43  0.23 bit

-xtreme

[...]
Listening  X    Vote for X:=B  OK    13/19    5.98557  0.14 bit           
Listening  X    Vote for X:=A  OK    14/20    8.67165  0.16 bit           
Listening  X    Vote for X:=B  OK    15/21    12.7626  0.18 bit           
Listening  X    Vote for X:=A  OK    16/22    19.0553  0.20 bit           
Listening  X    Vote for X:=A  OK    17/23    28.8270  0.22 bit           
Listening  X    Vote for X:=A  OK    18/24    44.1387  0.23 bit           
Listening  X    Vote for X:=A  OK    19/25    68.3373  0.25 bit           
Listening  X    Vote for X:=A  OK    20/26    106.891  0.26 bit           
Listening  X    Vote for X:=B  OK    21/27    168.787  0.28 bit           
Listening  X    Vote for X:=A  -    21/28    79.7388  0.23 bit           
Listening  X    Vote for X:=A  -    21/29    41.4602  0.19 bit           
Listening  X    Vote for X:=B  OK    22/30    62.0163  0.20 bit           
Listening  X    Vote for X:=B  OK    23/31    93.6870  0.21 bit           
Listening  X    Vote for X:=B  OK    24/32    142.850  0.23 bit           

-insane

[...]
Listening  X    Vote for X:=A  OK    22/35    5.69913  0.07 bit           
Listening  X    Vote for X:=B  OK    23/36    7.54727  0.08 bit           
Listening  X    Vote for X:=B  OK    24/37    10.1141  0.09 bit           
Listening  X    Vote for X:=B  OK    25/38    13.7078  0.10 bit           
Listening  X    Vote for X:=A  OK    26/39    18.7787  0.11 bit           
Listening  X    Vote for X:=A  OK    27/40    25.9893  0.12 bit           
Listening  X    Vote for X:=A  -    27/41    16.7831  0.10 bit           
Listening  X    Vote for X:=B  -    27/42    11.3084  0.08 bit           
Listening  X    Vote for X:=B  OK    28/43    15.1529  0.09 bit           
Listening  X    Vote for X:=B  OK    29/44    20.5058  0.10 bit           
Listening  X    Vote for X:=A  OK    30/45    28.0129  0.10 bit           
Listening  X    Vote for X:=A  OK    31/46    38.6159  0.11 bit           
Listening  X    Vote for X:=B  OK    32/47    53.6946  0.12 bit           
Listening  X    Vote for X:=A  OK    33/48    75.2826  0.13 bit           
Listening  X    Vote for X:=B  OK    34/49    106.392  0.14 bit           
Listening  X    Vote for X:=B  OK    35/50    151.505  0.14 bit

It does take a while to pick up on the problem, but once you know its there and what it is, its not so hard to identify it. All results are highly significant.

Also, -insane doesn't seem to improve upon -xtreme, but that could be because I did the encodes in sequence, and started to hear the problem better.

--
GCP

Possible MPC problem (Was: Crap MPC!)

Reply #8 –
I believe that you are actually hearing a problem in the hihat.wav sample and have ever since you informed me that you were able to ABX it.  I just don't think it is related to this supposed case since both the original poster and the other person commenting on it have kind of become silent and so far there has been no proof yet (via abx results or even a sample of the original).  So again, I think hihat.wav is an isolated case.  Basically, I'm saying that mpc doesn't have these problems on hihats as a general rule as was implied by some in other sections of the previous thread.  One of the very reasons I use MPC is because it performs far better on percussive sounds than other formats I have used.

Btw, how does vorbis do on hihat?  And has anyone tried encoding it with a good AAC encoder?  We know that MP3 has some big problems with this clip at least, and that MPC did perform quite well overall even if it is not 100% transparent.  It'd be interesting to see how other formats fair on this clip for comparison.

Possible MPC problem (Was: Crap MPC!)

Reply #9 –
Quote
Originally posted by Dibrom
Basically, I'm saying that mpc doesn't have these problems on hihats as a general rule as was implied by some in other sections of the previous thread.  One of the very reasons I use MPC is because it performs far better on percussive sounds than other formats I have used.


I think that, if MPC has problems, they're not due to transients but due to very noisy instruments, like hihats, cymbals or some guitars. I'm not saying it always artifacts there, just that if it does, that are the most likely candidates.

IIRC there were issues on dogies too, but that did not use a standard settings, and even then I didn't spot problems on my first tries. If you want to, I'll try -standard again sometime.

Quote
Btw, how does vorbis do on hihat?


I expect RC2 to suck, but my tuned mode should do better

(I'm at my parents place without listening equipment save the PC speaker, so I cant test)

--
GCP

Possible MPC problem (Was: Crap MPC!)

Reply #10 –
Quote
Originally posted by Garf
I think that, if MPC has problems, they're not due to transients but due to very noisy instruments, like hihats, cymbals or some guitars. I'm not saying it always artifacts there, just that if it does, that are the most likely candidates.


This is possible.  I just think that these situations resulting in any sort of audible artifacts are quite rare.  Some of the best ears I know absolutely swear by MPC so that and the fact that I've confirmed it time and time again with my own tests lead me to believe this is not a common issue at all.

Quote
IIRC there were issues on dogies too, but that did not use a standard settings, and even then I didn't spot problems on my first tries. If you want to, I'll try -standard again sometime.


I wouldn't be surprised at this at all.  The dogies clip used a preset based on -radio and then modified downward to lower the bitrate further.  Not only is this not a situation MPC will ever likely be used in (the custom switches at such a low quality setting) but MPC being a subband coder naturally isn't supposed to perform as well as transform coders at these lower bitrates (~128kbps).  The fact that it came out equal to or slightly above AAC was pretty impressive though.  However, I don't think anyone serious about quality would really be using 128kbps and expecting transparency either.  If you would like to encode it again though sometime with a more realistic setting that might be helpful, but it is up to you.

Possible MPC problem (Was: Crap MPC!)

Reply #11 –
Quote
Originally posted by Dibrom

Some of the best ears I know absolutely swear by MPC 


Note that that is by no means an argument to support the position that is has nearly never audible artifacts. It's an indication it has less than other codecs. That doesn't imply it has nearly none.

(Your other argument and your conclusion are valid AFAIK, I'm just nitpicking on this argumentation)

Quote
The fact that it came out equal to or slightly above AAC was pretty impressive though.


And who was the one that kept saying MPC should be included, very much to the dislike of the MPC advocates who kept saying it shouldn't because it wasn't optimized for that bitrate? 

... isn't it ironic, don't you think? ...

--
GCP

Possible MPC problem (Was: Crap MPC!)

Reply #12 –
Quote
Originally posted by Garf
Note that that is by no means an argument to support the position that is has nearly never audible artifacts. It's an indication it has less than other codecs. That doesn't imply it has nearly none.

(Your other argument and your conclusion are valid AFAIK, I'm just nitpicking on this argumentation)


I didn't say it "nearly never" has audible artifacts.  I said in these situations I don't believe it usually has audible artifacts (note the "quite rare" part).  Under the situation you described, MPC may be more suspectable to artifacts than in other situations, I'm just saying I don't think it usually results in big audible problems as were implied earlier in this thread.

Basically all this talk of hihat.wav has nothing to do with the earlier discussion IMO.  There hasn't even been any sort of confirmed problem however people have stated that "hihats cause problems for MPC", which isn't the case as a general rule.  I define "problems" in this case as nasty audible artifacts which are worse than what you might hear in other codecs.

Quote
And who was the one that kept saying MPC should be included, very much to the dislike of the MPC advocates who kept saying it shouldn't because it wasn't optimized for that bitrate? 

... isn't it ironic, don't you think? ...


Yes it is  The fact remains though that MPC is not used in this manner nearly 99% of the time people encode with it.  It was nice to see it perform pretty well, but negative results don't really mean much there IMO.

Possible MPC problem (Was: Crap MPC!)

Reply #13 –
Quote
I define "problems" in this case as nasty audible artifacts which are worse than what you might hear in other codecs.


Aah, in that case, I withdraw my objection. I was thinking about problem == nontransparent.

Quote
The fact remains though that MPC is not used in this manner nearly 99% of the time people encode with it. It was nice to see it perform pretty well, but negative results don't really mean much there IMO.


Oh they do. It means that the case for other codecs isn't totally hopeless

--
GCP

Possible MPC problem (Was: Crap MPC!)

Reply #14 –
Quote
Originally posted by Garf

Aah, in that case, I withdraw my objection. I was thinking about problem == nontransparent.
-- 
GCP

Yeah, I think the question here was that some hihat sounds bad. Vorbis and MP3 at highest bitrates are much more "nontransparent" here...
Juha Laaksonheimo