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.
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.
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).
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.
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] (http://index.php?act=findpost&pid=266642")
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
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] (http://index.php?act=findpost&pid=266642")
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]
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.
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] (http://index.php?act=findpost&pid=266642")
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.
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 ?
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 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 ...
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.
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.
To confuse things even farther, it ain't modified in any way, just other compiler used.
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 ?
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?
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.
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.
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?
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 msvcAll 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.
Anyone who wants a copy of ak's GCC compile (fixed encoder) can get it here (http://users.tpg.com.au/chirano/mppenc-1.15s.zip) until something else becomes available.
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.
Some more ABX tests by Pio2001 here (http://www.hydrogenaudio.org/forums/index.php?showtopic=30875) the results do not favor the GCC compile.
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.
G-R-E-A-T !
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........
Time for some order in the chaos we've created:
There is no bug in MSVC. We are experimenting with different compiler settings based on Frank's advice, to find out which ones are safe. ak's first GCC compile should not be used by anyone. It only fixed one obvious problem but it creates others.
The official Windows compiles are indeed made by MSVC but there is nothing wrong with them. My suggestion is to just wait one more day before the new official version is released for both Linux and Windows. You don't have to worry about 1.15s or which compiler was used. Stick to official builds only.
Thanks Seed.....