Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[bob]

Thanks for the test files Alex. I'm sort of stuck here. The max/min value checking at 32 bits is working and the files I've encoded with the musepack encoder in MC (the latest code from musepack.org) work perfectly in 32 bit mode. Your test files sound like crap in 32 bit but ok in 16. Since mine exceed the max/min values ocassionally too, I'm not seeing where the problem is. I'm probably going to remove the 32 bit output option for now.

[Alex B]

Thanks for the test files Alex. I'm sort of stuck here. The max/min value checking at 32 bits is working and the files I've encoded with the musepack encoder in MC (the latest code from musepack.org) work perfectly in 32 bit mode. Your test files sound like crap in 32 bit but ok in 16. Since mine exceed the max/min values ocassionally too, I'm not seeing where the problem is. I'm probably going to remove the 32 bit output option for now.

Mine was encoded with MC too (I used --quality 8 --ms 15 in the custom dialog). Could the quite high bitrate have something to do with this? The original audio sample itself is not compressed, clipped or otherwise unusual.

As far as I know all lossy encoders can produce peek values over 100% if you mean that.

Here is an example of an Ogg Vorbis file (fb2k display):

bitrate = 101
channels = 2
samplerate = 44100
bitrate_nominal = 88
codec = Vorbis
vorbis_vendor = Xiph.Org libVorbis I 20050304
replaygain_track_gain = -6.32 dB
replaygain_track_peak = 1.204611
 ----------
431298 samples @ 44100Hz
File size: 127 521 bytes

Here is my test sample:

bitrate = 276
samplerate = 44100
channels = 2
mpc_profile = 'BrainDead'
mpc_encoder = --Alpha-- 1.15
mpc_streamversion = 7
mpc_accurate_length = yes
codec = Musepack
replaygain_track_gain = -2.02 dB
replaygain_track_peak = 0.848067
 ----------
1323000 samples @ 44100Hz
File size: 1 035 383 bytes

Track peak 1 = 100%

Sometime ago I was curious why this happens and asked that here:

http://www.hydrogenaudio.org/forums/index.php?showtopic=38830

The answers I got from Gabriel and SebastianG explained a bit. This thing may have something to do with the behavior we are experiencing now. I wonder how the fb2k developers avoided this problem. Apparently it can handle a decoded 32-bit stream fine.

I think at one stage your plug-in had no problems with 32-bit audio quality (after you fixed the first quality problem), but I am not sure anymore. I would have to retest that plug-in version.

I wonder if I should ask opinions about the samples at HA forums. Someone might know what would typically cause errors like this. Or could you try the Tech forum at musepack.net ? You could provide a link to my test samples.

It's a pity if you can't find a solution to this problem. I already planned a test procedure that might have made the 16-bit and 32-bit difference audible (... or then not, but at least that would have been very interesting). I would have used a selected audio sample, various heavy DSP effects and Disk Writer output. Then I would have ABX tested the output files.

[bob]

Looks like the problem was not in the plugin 

It should be fixed in the next build...

[bob]

I just tried the last plugin with 11.1.108 and it seems that the 32 bit musepack output is working right now (at least as far as I can hear with your samples) 

[Alex B]

Yes, it seems to work now. I have not listened it critically, but the obvious "warbling" artifact has disappeared.

There may be a problem with Handheld conversions. Yesterday I tried Handheld sync (a folder configured as a device). My APE files converted fine to MP3, but MPC didn't work for some reason (the plug-in was in 16-bit mode).

[bob]

Ok, I just tried the upload to a handheld with conversion from mpc to mp3 with a creative zen micro and 11.1.108 and it worked great in 16 bit mode. Just to make sure we have exactly the same plugin (I did a couple of cleanups since the last post) I've put it up again. 3.1.2.2g.

http://accessories.musicex.com/mediacenter/mc_data/plugins/786.mjp

[Alex B]

I have the f version. I'll try g and report back.

[skeeterfood]

What happened to the plugin?

I upgraded to the latest beta tonight, went to install the updated MPC plugin and the 786.zip file is missing 

-John

[Alex B]

I don't know what happened to it. Bob, did you change something?

Here is a temporary location: MC111_inmpc.zip
Download, unzip and install. (Double-click the .mjp file in Windows Explorer. I modified it for local use.)


I have not had time to test the last version thoroughly, but so far it has worked fine.

[bob]

Sorry, I ran into a plugin numbering conflict. It's back in place now, same place as before:

http://accessories.musicex.com/mediacenter/mc_data/plugins/786.mjp

[skeeterfood]

Any chance we can get this included in the next 11.1 build?  I'm getting tired of re-installing it

-John

[Alex B]

Things are looking pretty good now:


Musepack

11.1.120 (02/13/06)
3. NEW: Includes new MPC decoder. (thread safe, decodes latest MPC files, supports 32-bit output, etc.)

MP3

11.1.122 (02/15/06)

13. NEW: Added option to use super-fast Go-Go encoder to MP3 encoder. (2x-3x faster for doing on-the-fly conversion for handhelds, UPnP, etc.)

Thanks. It looks fine:



I suppose many users will like this option whenever time is short.


Ogg Vorbis

11.1.123 (02/16/06)
13. NEW: Updated Ogg Vorbis encoder to version 2.8 (libvorbis version 1.1.2)

Thanks for this too!

However, I am curious why you chose this version (Oggenc2.8 using libVorbis v1.1.2 with IMPULSE_TRIGGER_PROFILE Option 2005-12-08) instead of the aoTuV b4.51 version (Oggenc2.8 using aoTuVb4.51 2005-12-08) ?

from: http://www.hydrogenaudio.org/forums/index.php?showtopic=39546&view=findpost&p=348793

Q: Sorry I think I missed something... libvorbis is now 1.1.2 ? how does it relate to aoTuVb4.51 ?
A: libvorbis 1.1.2 is the official Vorbis library coming out from Xiph.Org that is mostly based on the old aoTuV beta 2. aoTuV beta 4.5 is Aoyumi's tuned version of libvorbis (based on libvorbis 1.1.1).

Aoyumi has developed his Vorbis encoder version about two years after the beta 2 version. Beta 4.51 is the much praised test winner.

EDIT

The encoder differences are explained further in that HA thread.

[Alex B]

I tested the Go-Go speed with various settings @ 192 kbps:

Test PC: a 2.8 GHz P4
Test file: a disc image wave file, 477 MB, 47 min 20 s (Enigma - Voyageur).

Go-Go

-a -b 192 -m j    50 s     (abr 192, joint stereo)
-a -b 192 -m j -q 2    62 s    (abr 192, joint stereo, high quality)
-b 192 -m j -q 2    62 s    (cbr 192, joint stereo, high quality)
-b 192 -m j    53 s    (cbr 192, joint stereo)
-b 192 -q 2    68 s    (cbr 192, high quality)
-b 192    52 s    (cbr 192)

LAME (standard MC options)

VBR High, Fast    191 s
ABR 192    198 s
CBR 192    196 s

Go-Go is 3-4x faster. I think I'll use the "gogo.exe -a -b 192 -m j -q 2" custom command line for the CD-RW discs I burn for my car stereo. It should produce the highest quality at about 192 kbps. Though, I am going to try an ABX listening test soon.

[Alex B]

I have now encoded a few albums with Go-Go using "gogo.exe -a -b 192 -m j -q 2". The results are very promising. I have compared the original ape files and the mp3 files. With high-end headphones I can occasionally hear some differences, but when I listen to the mp3 files separately I don't notice anything annoying. The mp3 files may be slightly different, but in general the audio quality is just fine. I think they are good enough for my car and portable MP3 CD players.

It would be nice if the iPod users could try this setting. Since it is ABR and has less bitrate fluctuation, it is possible that it fixes the high bitrate LAME VBR skipping problem.

On my P4 system it is over 3x faster than LAME VBR High Fast and because the encoding mode is ABR the resulting bitrate is more predictable too. The smallest file has been about 180 kbps and the biggest about 200 kbps so far. The average bitrate seems to be very near the 192 kbps target value.

Any target bitrate is possible so command line strings like "gogo.exe -a -b 165 -m j -q 2" and "gogo.exe -a -b 208 -m j -q 2" are fine.