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: Killer sample (Read 22275 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Killer sample

Both Musepack encoder versions: 1.14 & 1.15s fail on this sample at all settings up to q10. This synthetic sample was created using Fruity Loops 4.5. It is repeated kick sound.
stimulating the audio nerve directly

Killer sample

Reply #1 –
I tried encoding with Q2 (mppenc 1.15s) and paradoxically the result is better than the one obtained with higher quality settings (maybe still abx-able, but not as flagrant as with, say, Q5).

Bye.

Killer sample

Reply #2 –
Standard 44.1 16bit stereo sample.  Adding silence at the beginning helps that first beat, but the main problem is still there.  Xlevel doesn't help.  The sample, unlike most music you'll hear,does include true silence in between each beat.

...

Yes, mixing some low level sound into the sample makes a huge difference, from obvious to transparent (except at the start).
"All I ask is that composers wash out their ears before they sit down to compose." - Morton Feldman

Killer sample

Reply #3 –
I was curious, downloaded the sample and did a test encode with LAME, OggVorbis and Musepack 1.14, 1.15s.

The decoded version of both Musepack Samples shows in CoolEdit's Waveform Window wrong phasing of some of the 'pulses', which is very audible too.

I guess this is a bug of the musepack encoders. Both LAME and OggVorbis encoded samples are okay regarding phasing.

Killer sample

Reply #4 –
Quote
The decoded version of both Musepack Samples shows in CoolEdit's Waveform Window wrong phasing of some of the 'pulses', which is very audible too.
[{POST_SNAPBACK}][/a]

Could you try this one: [a href="http://4nykey.nm.ru/tmp/mppenc-1.15s.zip]http://4nykey.nm.ru/tmp/mppenc-1.15s.zip[/url] (gcc compile).
Produces ~10kbps bigger bitrate on this one (at q5), but no such artifacts (afaics

Killer sample

Reply #5 –
Quote
Quote
The decoded version of both Musepack Samples shows in CoolEdit's Waveform Window wrong phasing of some of the 'pulses', which is very audible too.
[{POST_SNAPBACK}][/a]

Could you try this one: [a href="http://4nykey.nm.ru/tmp/mppenc-1.15s.zip]http://4nykey.nm.ru/tmp/mppenc-1.15s.zip[/url] (gcc compile).
Produces ~10kbps bigger bitrate on this one (at q5), but no such artifacts (afaics
[a href="index.php?act=findpost&pid=266651"][{POST_SNAPBACK}][/a]


Code: [Select]
ABC/HR Version 1.0, 6 May 2004
Testname: 

1R = C:\Temp\teh sample 1_15s new.wav
2L = C:\Temp\teh sample 1_15s old.wav

---------------------------------------
General Comments:

---------------------------------------
ABX Results:
Original vs C:\Temp\teh sample 1_15s new.wav
    6 out of 17, pval = 0.928
Original vs C:\Temp\teh sample 1_15s old.wav
    17 out of 17, pval < 0.001

Tested at q7/insane, new encoder sounds transparent to me.

Killer sample

Reply #6 –
Quote
Quote
The decoded version of both Musepack Samples shows in CoolEdit's Waveform Window wrong phasing of some of the 'pulses', which is very audible too.
[{POST_SNAPBACK}][/a]

Could you try this one: [a href="http://4nykey.nm.ru/tmp/mppenc-1.15s.zip]http://4nykey.nm.ru/tmp/mppenc-1.15s.zip[/url] (gcc compile).
Produces ~10kbps bigger bitrate on this one (at q5), but no such artifacts (afaics
[a href="index.php?act=findpost&pid=266651"][{POST_SNAPBACK}][/a]

Thanks.  That works great.

Apparently we just need the binary releasers to stop using lossy compilers. 
"All I ask is that composers wash out their ears before they sit down to compose." - Morton Feldman

Killer sample

Reply #7 –
Weird, the gcc compile for linux create bit-identical files to the MSVC compile for windows. ( talking about binaries hosted on musepack.net )

What settings has been used for this compilation ?
It's a 'Jump to Conclusions Mat'. You see, you have this mat, with different CONCLUSIONS written on it that you could JUMP TO.

Killer sample

Reply #8 –
Quote
Weird, the gcc compile for linux create bit-identical files to the MSVC compile for windows. ( talking about binaries hosted on musepack.net )

What settings has been used for this compilation ?
[a href="index.php?act=findpost&pid=266862"][{POST_SNAPBACK}][/a]

All the settings.

Definitely not bit identical.  GCC is 132096 bytes.  Musepack.net compile is 80384.
"All I ask is that composers wash out their ears before they sit down to compose." - Morton Feldman

Killer sample

Reply #9 –
Quote
All the settings.

Definitely not bit identical.  GCC is 132096 bytes.  Musepack.net compile is 80384.
[a href="index.php?act=findpost&pid=266865"][{POST_SNAPBACK}][/a]


The linux compile, and the windows compile, the versions hosted on musepack.net produce bit-identical musepack files. And this with two different compilers, gcc and msvc.

Of course the executables themselves aren't bit-identical ...
It's a 'Jump to Conclusions Mat'. You see, you have this mat, with different CONCLUSIONS written on it that you could JUMP TO.

Killer sample

Reply #10 –
Quote
Weird, the gcc compile for linux create bit-identical files to the MSVC compile for windows. ( talking about binaries hosted on musepack.net )

What settings has been used for this compilation ?
[a href="index.php?act=findpost&pid=266862"][{POST_SNAPBACK}][/a]

I checked with linux compile (built from sources), no such problem either.
Looks like resetting CFLAGS to defaults triggers that though. I'll try to play with cflags to figure which one helps.

...
Well, fwiw, simply adding '-march=i686' to those default (using svn from musepack.net) seems to be enough.

Killer sample

Reply #11 –
Hi! Another confirmation from me. The sample is now transparent to me.

Is this modified version now a (official) recommend encoder?
If so, I suggest to change its name to 1.15t to avoid confusion about different versions with the same name.

Killer sample

Reply #12 –
To confuse things even farther, it ain't modified in any way, just other compiler used.

Killer sample

Reply #13 –
Huh, we need to know first what is the cause of this.
This gcc compile has a different behaviour, not only with this sample. It's too early to just assume it is consistently better than the previous binary.

Random-guess: AK, can you try march=i686 and --ffast-math ?
It's a 'Jump to Conclusions Mat'. You see, you have this mat, with different CONCLUSIONS written on it that you could JUMP TO.

Killer sample

Reply #14 –
Quote
To confuse things even farther, it ain't modified in any way, just other compiler used.
[a href="index.php?act=findpost&pid=266887"][{POST_SNAPBACK}][/a]

Does that mean the bug was caused by the compiler used to code the 'original' release of musepack 1.15s for windows platform?

Killer sample

Reply #15 –
1. It's too early to call anything 1.15t. A serious investigation is in order first. Will the person who compiled this binary please contact me?

2. The new binary creates different MPCs for many known problematic samples. Examples: Walkyries_short.ape (--insane): Official 1.15s = 257.1 kbps. New compile = 240.6 kbps. fsol.flac (--insane): Official 1.15s = 265.1 kbps. New compile = 263.8 kbps.

Please don't jump to conclusions before we know what's wrong. Don't forget that Nero and Wavpack failed in a similar way to the official mppenc build. We will test this thoroughly and post our conclusions.
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien

Killer sample

Reply #16 –
fast-math is in default cflags already, which are:
-O3 -ffast-math -fomit-frame-pointer -funroll-loops  -fmove-all-movables -falign-jumps=5 -falign-loops=0 -falign-functions=5
So in the end at commandline gcc gets those + -mrach appended at the end.

Killer sample

Reply #17 –
I want to know if anyone can come up with another sample that the new compile encodes differently and they can hear a difference between it and a file the official 1.15s compiles produce.

guruboolez, can you encode Walkyries_short with the new encoder and test if there's a difference in how it sounds?
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien

Killer sample

Reply #18 –
Quote
I want to know if anyone can come up with another sample that the new compile encodes differently and they can hear a difference between it and a file the official 1.15s compiles produce.

guruboolez, can you encode Walkyries_short with the new encoder and test if there's a difference in how it sounds?
[a href="index.php?act=findpost&pid=266897"][{POST_SNAPBACK}][/a]

Guru deserves a rest.

mpc15s gcc vs. mpc15s msvc

All ABX tests done with --insane.  Tested each encoded version against the original.  No new problems introduced.  At the same time ... as a final test, I tried this out with the Bloch_Formule sample that I was able to ABX with 1.14.

Walkyries_short GCC 14/25
Walkyries_short MSVC 12/25
Fatboy GCC 11/25
Fatboy MSVC 14/25
BeautySlept GCC 14/25
BeautySlept MSVC 8/25
Bloch_Formule GCC 10/25
Bloch_Formule MSVC 17/25

Couple more notes:
* I tried encoding a couple albums with 15s GCC.  No obvious problems and the mpcscan tool verified all the frames were written correctly.
* The MSVC files are bigger (higher bitrate) than the GCC in all the samples other than teh_sample.

No more MSVC for me, thank you.  And a big thank you to ak for pointing this out.
"All I ask is that composers wash out their ears before they sit down to compose." - Morton Feldman

Killer sample

Reply #19 –
Anyone who wants a copy of ak's GCC compile (fixed encoder) can get it here until something else becomes available.

Killer sample

Reply #20 –
The Musepack Development Team (including ak) is working hard on a complete solution. We're thoroughly testing the quality of new builds with the kind help of Frank Klemm. Please be patient and do not adopt ak's current build. teh_sample is not the only sample it deals with differently and it's too risky to assume it's ready for using.

We'll notify the community as soon as we have a fixed binary.
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien
 

Killer sample

Reply #21 –
Some more ABX tests by Pio2001 here the results do not favor the GCC compile.

Killer sample

Reply #22 –
Pio2001 is testing an encoder that sounds much better than the "GCC" one you all test. There's absolutely no reason to keep it. It's flawed. Please be patient and we'll release a new mppenc soon.

Edit: Don't panic. Only the first build ak released is flawed. There's nothing wrong with whichever official encoder you use. We did improve amnesia over the old GCC build from ak, but 1.15r and 1.15s are not inferior to our build, except for "teh sample" which is 100% fixed now.
And if Warhol's a genius, what am I? A speck of lint on the ***** of an alien

Killer sample

Reply #23 –
G-R-E-A-T !
stimulating the audio nerve directly

Killer sample

Reply #24 –
I'm confused!!!

The bug in mppenc 1.15s MSVC is a bug that affects only one or two killer sample or is a "quality" bug that affects all track with a loss of quality??

GCC compile is better than MSVC compile??

And what it mean that bug 1.15s is fixed now?? There is a new version??

Thanks........