new Open Source mp3 Encoder from Helix Community Options

[QuantumKnot]

Guess I found a BUG 

On some music files (wav), the encoder creates mp3s, that play skippy on some players. I tested J.River Media Center, Media Player Classic, FFDShow Audio Decoder and Winamp.

It plays fine on Winamp and FFDSHOw, and skippy on the two others.

Any idea what's going on? I dunno if it is a problem of the encoder or of the player?? All I noticed that the files have very low bitrate, compared to other files created with the same parameters: "-v90 -x2 -u2 -HF2"

You can get a sample of the skippy file here:
Skippy File

Please help me, this bug is making me anxious about my music.

Thx
Rüdiger

I had a listen to the file in both foobar2k and mediaplayerclassic, where I heard some skipping in the latter. It's very strange since I've heard something similar in one of my other files that was encoded using Helix mp3. It plays fine on my iPod, foobar2k (and media player classic as I just checked), but it skips in a bad way (like the file was cooked) when played in amarok on linux, which is currently using the mad mp3 decoder I believe.

This post has been edited by QuantumKnot: Dec 2 2005, 13:44

[Rüdiger]

I found another broken file which DOESN'T PLAY CORRECTLY EVEN on my Ipod!!

Only player working ATM seems to be Winamp. But hardware players fail as do all other software players!!

Please, developers take a look at your source code.
I found out that the error seems to be related to default stereo mode 1, switching to mode 0 the error is gone, but the resulted file is much bigger. I hope you can find the error with the information provided.

Thanks
Rüdiger

P.S. I did the encoding on several machines, the error is always there.

This post has been edited by Rüdiger: Dec 9 2005, 20:36

[level]

I found another broken file which DOESN'T PLAY CORRECTLY EVEN on my Ipod!!

Only player working ATM seems to be Winamp. But hardware players fail as do all other software players!!

Please, developers take a look at your source code.
I found out that the error seems to be related to default stereo mode 1, switching to mode 0 the error is gone, but the resulted file  is much bigger. I hope you can find the error with the information provided.

Thanks
Rüdiger

P.S. I did the encoding on several machines, the error is always there.

What this is strange. I have encoded at least 30 original albums of my private collection for portable use, using my command line: -V120 -X2 -HF2 -SBT450 -TX0; and I have not had problems at all. In home, I have used in my PC Winamp, Foobar, Media player without problems. In my TV and sound equipment room, I have a DVD player Philips that play mp3s. With this DVD player no problems too.

Could you upload the sample that is causing the problems? Thanks..

[Rüdiger]

Sorry for the delay, but now I uploaded several files in a small RAR.
http://rapidshare.de/files/9028251/brokenhelix.rar.html

The source.wav contains 10 seconds of the problematic CD.
File was encoded using Helix with my common parameters -V90 -X2 -HF2 -SBT450 -TX0, as well as with your parameters -V120 -X2 -HF2 -SBT450 -TX0 (Helix90.mp3 & helix120.mp3). Additionally I encoded the sample with lame 3.98 as well as with old Xing Encoder 1.5.

The Helix files play OK in winamp, but not with J.River Media Center nor with Media Player Classic. MPC plays skippy, Media Center creates distortion, independent wether -v90 or -v120 was used. For all people not being able to reproduce the bad playback, I decoded the helix90 file with Media Center to a wav file, so you can hear the error in every player.

About hardware players: My Nex playes the files OK AFAIK, but my Sony Carradio creates exactly the same distortion as Media Center.

The old Xing file and the Lame file do not have these problems with the sample.

Again, the error disappears in Helix files when encoding with stereo mode 0 instead of default mode 1, so the error must be somewhere there.

Please check this.
Thanks
Rüdiger

[Gabriel]

but my Sony Carradio creates exactly the same distortion as Media Center.

To me this could be caused by using different block sizes between left and right. Sony car players are notoriously unable to handle this, while this is perfectly compliant with the mp3 standard.

If this is confirmed to be the cause of the problem, problematic software decoders should be updated (if possible) to fix this.
Real should also be notified of this potential problem.

edit: it would be usefull to be able to have a look at the problematic file (ie upload it somewhere that does not requires a registration)

This post has been edited by Gabriel: Dec 12 2005, 12:43

[kritip]

Its a bit confusing but you don't need to register to download, you scroll to the bottom, click on Free!, enter the verification code at the bottom of the screen and then you have to wait about 20s for the DL to begin,

KRistian

This post has been edited by kritip: Dec 12 2005, 12:58

[Rüdiger]

Rapidshare doesn't require registration.

If the error is caused by different block sizes between left and right as described by Gabriel, some kind of "compatibility switch" would be nice to create files that are playable by all hardware players.

Using stereo mode 0, block size might be different for left and right as well, no? Cause I think stereo 0 is only left and right encoding, without the usage of joint stereo (MS encoding) as the files are bigger in VBR mode using stereo 0. So this couldn't be the problem then...

I hope some of the Helix developers jump into that discussion soon.
Thanks
Rüdiger

[karl_lillevold]

Hmm, seems like a bug, but I am afraid I can not directly help. I have forwarded this thread to my audio codec colleague, but I worry he may not have time to look into it. If anyone else has time, the encoder is open source...

[Alex B]

The Helix files play OK in winamp, but not with J.River Media Center nor with Media Player Classic. MPC plays skippy, Media Center creates distortion, independent wether -v90 or -v120 was used. For all people not being able to reproduce the bad playback, I decoded the helix90 file with Media Center to a wav file, so you can hear the error in every player.

Could you report this at J. River's forum and provide them a sample? They tend to fix occasional MP3 problems quickly (if possible, like Gabriel said).

[Rüdiger]

The Helix files play OK in winamp, but not with J.River Media Center nor with Media Player Classic. MPC plays skippy, Media Center creates distortion, independent wether -v90 or -v120 was used. For all people not being able to reproduce the bad playback, I decoded the helix90 file with Media Center to a wav file, so you can hear the error in every player.

Could you report this at J. River's forum and provide them a sample? They tend to fix occasional MP3 problems quickly (if possible, like Gabriel said).

I reported the first recognized error to J.River and they fixed it, bt as the second one appeared also on some of my hardware players, I thought that it would be more intelligent to fix the encoder instead of building a workaround on decoder site, since this can only be done for software decoders ;(

So please try to improve the encoder towards a more compatible file creation. Otherwise, I would have to leave this really great and fast encoder, because whats the use of such an encoder if the created files do not play properly on my hardware devices...

Thanks
Rüdiger

This post has been edited by Rüdiger: Dec 14 2005, 01:38

[JimH]

The Helix files play OK in winamp, but not with J.River Media Center nor with Media Player Classic. MPC plays skippy, Media Center creates distortion, independent wether -v90 or -v120 was used. For all people not being able to reproduce the bad playback, I decoded the helix90 file with Media Center to a wav file, so you can hear the error in every player.

Could you report this at J. River's forum and provide them a sample? They tend to fix occasional MP3 problems quickly (if possible, like Gabriel said).

I reported the first recognized error to J.River and they fixed it,

Here's what we found at J. River:

http://yabb.jriver.com/interact/index.php?...09701#msg209701

[Gabriel]

I reported the first recognized error to J.River and they fixed it, bt as the second one appeared also on some of my hardware players, I thought that it would be more intelligent to fix the encoder instead of building a workaround on decoder site, since this can only be done for software decoders ;(

So please try to improve the encoder towards a more compatible file creation. Otherwise, I would have to leave this really great and fast encoder, because whats the use of such an encoder if the created files do not play properly on my hardware devices...

IF the issue is the one I am suspecting (different block sizes on both channels in stereo), then:
*this is perfectly compliant with the standard
*we already know that some Sony and Clarion car players are unable to handle this
*fixable decoders should be fixed

Changing the Real encoder for this case is possible, however if you disable features each time you encounter a specific decoder that is unable to handle it, you will end with many features disabled and decoders would never be fixed.
The part that should be changed is the decoder, which is not compliant, not the encoder.

because whats the use of such an encoder if the created files do not play properly on my hardware devices...

The real question is what's the use of such a decoder which is unable to decode compliant files.

In the case of the user reporting the problem, a workaround for him is easy: encode in joint stereo.

[Rüdiger]

[In the case of the user reporting the problem, a workaround for him is easy: encode in joint stereo.

Stereo mode 0 can't be joint stereo! Because stereo mode 0 creates bigger files compared to default stereo mode 1. And joint steréo should create smaller files, no?

I'm with you that the decoder should be fixed if the files created by the encoder are mpeg-compliant, but J.River stated in their forum that my sample files are "spliced / or slightly invalid MP3 files" so I thought that the encoder creates invalid files!! For comparison, old Xing encoder and Lame encoder create playable files. So where is the error now?

Thanks
Rüdiger

P.S.

The part that should be changed is the decoder, which is not compliant, not the encoder

Is there some kind of firmware update available for sony caraudio devices? I guess not, so the decoder cannot be fixed. Only solution would be an adapted encoder. I do not require that this error-causing blocking design should be diisabled by default, but only be available by an optional switch. Does Lame use such a technique? Because I don't get and errors using Lame on the same file?!?

This post has been edited by Rüdiger: Dec 14 2005, 22:40

[Rüdiger]

I take a look at the sourcecode. It seems this encoder use the same block-type for both-channels (for stereo of course).

I wonder how does LAME handle the situation when there's different type-selection for each channel. If they take different selection, and the summation of the criteria value agree taking long block, does it suffer the quality (one channel pre-echo maby)?

As I know, if different block types used, some decoders may have trouble with such situation, even it's part of mp3 standard.

OK, found this ín this thread. So, if Enig123 is right, the error cannot be a result of different block size in the channels.

[Alex B]

Media Center 11.1.81 Beta (12/14/05) « on: Today at 05:24:46 PM »

From the changelog:

11. Fixed: Some MP3's created by Helix in stereo mode would hiccup during playback in MC.

[Rüdiger]

OK, MC works now, but my car audio not.

If I understood correctly, Lame uses different block sizes only on dual channel encoding, and same block sizes on both channels on joint stereo.

Helix instead uses different block size on joint stereo which causes the problems with some decoders.

Now I can use Helix only with simple stereo (mode0),which creates bigger files in VBR mode.

I agree with Gabriel that limiting the encoder to same block sizes to fix this is a loss of capabilities, but having to use the encoder in simple stereo is even a bigger loss of functionality, I create bigger files with no quality-wise advantage.

Perhaps it would be possible to add a switch to Helix, which is only OPTIONAL, to do the block sizes in joint stereo as Lame does ???

If this is only an optional switch and not a hardcoded setting, it would even extend the capabilities of the encoder and not decrease it.

Thanks
Rüdiger

This post has been edited by Rüdiger: Dec 17 2005, 15:25

[karl_lillevold]

My colleague suggested the following instead:

I took a look at the Xing code, and I think it's a different problem. What's happening is the new encoder is writing the wrong value for scalefac_compress in certain situations. It's reusing an old value rather than writing 0 (i.e. no bits spent coding scalefactors).

I think the correct solution is to set this field to 0 when a null frame is encoded. This is what the Xing code does already in the "old" bit allocation functions and in MPEG2 mode. So I'm guessing it was just an oversight that this was not done for the updated ones.

I've attached a diff - just adds one line to each of two functions, encode_jointB() and encode_singleB(), to set the default value of scalefac_compress to 0. This gets overwritten by L3_pack_sf_XXX() if it's a non-null frame.

If anyone wants to try this out, I can compile a test exe... Let me know.

CODE

Index: mp3enc.cpp
===================================================================
RCS file: /cvsroot/datatype/mp3/codec/encoder/mp3enc.cpp,v
retrieving revision 1.2
diff -u -w -r1.2 mp3enc.cpp
--- mp3enc.cpp    9 Aug 2005 20:43:42 -0000    1.2
+++ mp3enc.cpp    20 Dec 2005 20:43:37 -0000
@@ -1556,6 +1556,7 @@
        for ( ch = 0; ch < nchan; ch++ )
        {
            bits = 0;
+            side_info.gr[igr][ch].scalefac_compress = 0;
            if ( shortblock_frame )
            {   // have a short, scfsi = 0
                side_info.scfsi[ch] = 0;
@@ -1713,6 +1714,7 @@
                           &sf[igr][0], &side_info.gr[igr][0], ix, signx, 0 );

        bits = 0;
+        side_info.gr[igr][0].scalefac_compress = 0;
        if ( shortblock_frame )
        {       // have a short, scfsi = 0
            side_info.scfsi[0] = 0;

[Drenholm]

Sorry to butt in... but where would be the best place to download latest executables of this encoder?

[karl_lillevold]

You can find the old version on Rarewares:
http://www.rarewares.org/mp3.html

and a version with the potential fix (diff above) from helix community:
Helix Binary Downloads

[john33]

New patched version also now at Rarewares.

[Rüdiger]

OK, already tested the new build on my problematic sample (Benassi Bros)

Seems to work now also using stereo mode 1 (JS)

I just tested this on an outdated version of J.River Media Center (without decoder bugfix), but I'll check it on my Sony CarAudio tomorrow morning as well.

THANKS, KARL, TO YOU AND YOUR COLLEAGUE!
I think you found it.

I'll report back after having checked on my CarAudio as well.
Thanks again
Rüdiger

[yong]

Does anyone tested it with stdin input? couldnt get it to work with fb2k or with cli...
Here is the switches im using with fb2k cli encoder "- %d -X2 -A1 -V50 -U2"

EDIT: oops... The version i downloaded form Rarewares does works, but from Helix binary download page doesnt.

This post has been edited by yong: Dec 21 2005, 08:08

[kwanbis]

i'm planing on adding it to MAREO's config file, what would be a good command line for:

1) best posible quality
2) medium
3) portable

[Rüdiger]

OK, Tested the new encoded files on my Car Audio and they work!

CHEERS!

Merry Christmas to everyone, Helix is now really a champ!

THX
Rüdiger

[Drenholm]

Thank you, Karl.