I found a problem with the new piping feature of the Helix encoder, I guess.

Using J.River Media Center 11, it is possible to use Helix as internal encoder (means ripping directly to mp3) by renaming the exe to Lame.exe and using the advanced command line parameter box.

Unfortunately, I don't have any benefit with regard to speed when using Helix in this scenario. The drive (52x CD-RW) doesn't spin up to max speed when using Helix encoder altough CPU load is only 30%, it rips only at 7x.

Using original lame.exe instead the drive speeds up correclty (you can hear it, it's quite noisy) and the speed goes up to 15x, faster is not possible because LAME creates so much cpu-load ;(

I guess it cannot be a problem of MC with my drive, since it works with lame-encoder piping and the drive itself can rip Audio-CDs with up to 32x (when using wave).

So I think it's a problem with the piping that keeps MC from speeding up the drive.
I also posted this behaviour in the MC forum.
http://yabb.jriver.com/interact/index.php?topic=29097.0
It would be really great if you could try to solve this problem together with J.River team.

Thanks a lot for this updated "Xing" encoder!!
Rüdiger

EDIT: Just found out, the Liteon has a feature called SMART-X t "optimize" DAE speed depending on used application, but since MC runs at fast speed with Lame, it really must be some kind of incompatibility between Helix and Smart-X. Nero DriveSpeed shows that using Helix Speed is limited by Smart-X to 8x, whereas with Lame it's theoretically up to 48x. Hope this helps

I'm using "on the fly encoding" in CDex with the following command:

- %2 -X2 -U2 -V80 -HF2 -F19000

The trick is ticking the "send wav header to stdin". After you select that, then away she goes

Has anyone tested the CML rev12 (Only for test) binary yet?

Guruboolez's test (mentioned http://www.hydrogenaudio.org/forums/index....howtopic=36062# ) uses rev12 with default settings.

All the contributed changes have been checked into CVS on helixcommunity, incl. the VS .NET standaline makefile. I also modified the ribosome build system Umakefil to use the pre-built asm optimized .obj files on Win32/x86, such that the encoder built from this should be the same speed as the one built from the standalone VS .NET makefile.

Thanks to everyone who contributed suggestions and improvements!

Hello Folks,

I'm wondering which switches are safe to use? I've been using only -X2 and -Vxx and sometimes -HF.

Also, when RealPlay says ~128kbps VBR, the equivalent in this encoder seems to be -v56. Can someone from Helix confirm this?

Edit: 8/20/05

I've been using the following settings:

-V135 -X2 -U2 -TX8 -HF2 -F19000

I wanted good sound quality whilst still playing on all iPods without skipping... LAME sound quality is good, but it's iPod compatibility is not.

hmm...I've been using CML MOD r11 with CDex and been doing on-the-fly encoding. I noticed there's a new CVS version on rarewares so I grabbed that. But now CDex doesn't work with it. It just says it had an error sending data to the external encoder. It works normally (without on-the-fly). I replaced it with the old r11 encoder and it works again. Did something break in the stdin input option of hmp3.exe ?

IIRC, the CVS version was supposed to be no more than the incorporation of the patches, etc., provided here. However, I didn't personally check to see whether anything was changed that would have broken any functionality. I'll compare the two versions later.

Hmmm, can't see anything obvious. I'll look closer later.

Thanks. Maybe it is a compiler issue?

stdin doesn't work for me either... had to use %s in fb2k.

Hmmm, well that was interesting - I'm actually surprised it functioned at all!!

I found and fixed the bug, and a new compile with amended source is at Rarewares now.

For anyone interested, take a look at the first line under the leading comment block of the previous 'tomp3.cpp' and you'll see '/*'. A comment starter that was left from a previous comment block that was removed along with the closing '*/'. As usual, looking for something complicated when it was, and usually is, something completely silly!!

double hurrah, works like a dream, thanks!

I don't know if I should mention it here but I found a sample with serious drop-outs (or whatever it is...) on the right channel at -V65. I have otherwise failed every attempt to ABX anything by HELIX at -V65 (and LAME -V 5!). But I just noticed this one while out running with my portable! I'm like, what is that noise?!? So I had to ABX it as soon as I got back home. I immediately re-encoded it with LAME and the problem was gone. I think I have to reproduce the file and see if it's still there...

I guess that's why we're testing it, if LAME solves your problems then LAME is the way to go.

Thank you so much!! I can't wait till I get home and try it.


EDIT: It works!! No progressive stats are printed out though, but who cares. As long as it encodes

Is anyone brave enough to do some ABX vs LAME at equivalent bit rates to V2?

Try -V150 -TX8 -X2 -HF2 -U2 -F19000, and compare with LAME 3.97b1 -V1 -vbr-new. Sorry to hark on, but this thing should be tested, I'm just sorry that I don't have time to do a properly documented ABX.

I apologise if I'm breaking the HA rules by not qualifying my demands by a proper ABX, but concensus is not always a good thing, it generally results in mediocrity, so treat me with the disdain of an outsider and I'll be happy.

After doing many ABX tests with distortion_guitar.wav and Originalsmall.wav I was able to improve the performance of encoder with these samples.

COMMENTS:

distortion_guitar.wav: the combination of SBT and TX switches improved remarkably the quality. The adequate values of SBT and TX did this sample very hard for ABX (almost transparent) [SBT=450; TX=0]

Originalsmall.wav: This sample is more ABXable, but, with SBT=450 and TX=0 the quality is a lot better. For a setting of -V120 -SBT450 -TX0 the result is the same as with -V150 without additional switches. This sample is easy ABX with aoTuV_b4 @q6.


MY COMMAND LINE: -V120 -X2 -HF2 -SBT450 -TX0

A explanation: This command line is the result of many ABX tests with many of my music and mainly with distortion_guitar.wav and Originalsmall.wav samples.

SBT switch: SBT<700 improves the performance; however, values of SBT<450 doesn't improve the sound; at least for my ears.

TX switch: It changes remarkably the sound quality. The strange thing is that to greater values of TX the bitrate increase and the sound quality is worse . I tested values in the range from 0 to 12; the best value (less artifacts with distortion_guitar.wav) was TX=0.

V switch [with SBT450 + TX0]: with my two difficult samples I found that for values V<120 the sound quality was worse in comparison with -V120. For values of V>120 the sound quality doesn't improve significantly.

HIGH FREQUENCY switch: I eliminated the -F19000, because seems that this adds something of extra phasing (very little) to distortion_guitar.wav; although I'm not sure, I need more testing for to be sure. However; pure -HF2 (without -F combination) has a cutoff in 19500 Hz; which the -F19000 switch is redundant.

MUSIC (The samples)
I tested [-V120 -X2 -HF2 -SBT450 -TX0] in my few free time the last two months with many of my music:

1) Kraftwerk - Computer World (217 kbps) [electronic]

2) Kraftwerk - Pocket Calculator (219 kbps) [electronic]

3) Marty Friedman - Tibet (196 kbps) [Instrumental rock]

4) Marty Friedman - Trance (189 kbps) [Instrumental rock]

5) Michel Petrucciani - Play Me (202 kbps) [Piano jazz]

6) Michel Petrucciani - Looking Up (198 kbps) [Piano jazz]

7) Cat Stevens - Wild World (170 kbps) [Acoustic guitar with male vocals]

8) Cat Stevens - Morning Has Broken (197 kbps) [Acoustic guitar with male vocals]

9) Santana - Black Magic Woman / Gypsy Queen (214 kbps) [Latin rock]

10) Santana - Waiting (218 kbps) [Latin rock]

11) Peter White - Café Mystique (233 kbps) [Smooth jazz]

12) Peter White - Long Ride Home (227 kbps) [Smooth jazz]

13) Marty Friedman - Angel (189 kbps) [Instrumental rock]

14) Yanni - The Mermaid (167 kbps) [New age]

15) Iron Maiden - The Ides Of March (198 kbps) [Heavy metal]

16) Iron Maiden - Wrathchild (205 kbps) [Heavy metal]

17) Pet Shop Boys - Left To My Own Devices (219 kbps) [Disco pop]

18) Pet Shop Boys - So Hard (217 kbps) [Disco pop]

19) Pet Shop Boys - It's Alright (220 kbps) [Disco pop]

20) Pendragon - The Voyager (205 kbps) [Symphonic rock]

21) Pendragon - Queen Of Hearts: (ii)...A Man Could Die Out Here... (221 kbps) [Symphonic rock]

22) Metallica - For Whom The Bell Tolls (205 kbps) [Metal]

23) Carpenters - Goodbye To Love (214 kbps) [Ballad with female vocals]

24) Yanni - Farewell (195 kbps) [New age]

25) Yanni - Almost A Whisper (168 kbps) [New age]

Range: 167 --- 233 / Average: 204 kbps

For my ears [-V120 -X2 -HF2 -SBT450 -TX0] was in ABX total transparent with all of these 25 songs of different music.

GENERAL CONCLUSION:
IMO based in my exhaustive ABX tests; Helix work as a champion (at least to my set of 25 songs). Of course, this is only my impression based in my ears.

Could please someone confirm this?

Another thing... my ears are not tuned for classical music, my test was based in my music, mainly rock, jazz and pop.

Could please someone with good ears in classical music to check whether my combination of switches is good or not? maybe... guruboolez?
I would appreciate much this.

Anyone?

Could you tell us what the "-TX" parameter is? The documentation (such as it is) left me in the dark. Thank you.

would these switches improve the quality at lower bit rates as well? For examle -V60? (around 140 kbps, for metal at least)

Sorry.. but.. I don't have idea that this switch does. The documentation available doesn't say anything with respect to this switch. However, it produces a really impact in the sound quality.
It reduces (as already mentioned) dramatically the warbling phasing problem in the distort_guitar.wav sample, where mainly, Helix has problems.

Could please Karl tell us what the "-TX" switch is?

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.

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..

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

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)

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

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

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...

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

Here's what we found at J. River:

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

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.


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.

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.

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?!?

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

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

From the changelog:

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

My colleague suggested the following instead:



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

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

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

New patched version also now at Rarewares.

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

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.

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

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

Thank you, Karl.