I just read this info from Karl here (http://forum.doom9.org/showthread.php?t=97287) in Doom9
We have open sourced our MP3 encoder under the RPSL/RCSL. It has been checked it in under datatype/mp3/codec/encoder
You can build it with the following example configuration in the ribosome build system:
bif: helix
target: datatype_mp3_codec_encoder
profile: helix-client-all-defines SYSTEM_ID=linux-2.2-libc6-gcc32-i586
Documentation is available here:
http://datatype.helixcommunity.org/2005/mp3enc.doc (http://datatype.helixcommunity.org/2005/mp3enc.doc)
Source is here:
https://helixcommunity.org/viewcvs/.../codec/encoder/ (https://helixcommunity.org/viewcvs/.../codec/encoder/)
Could be great if someone can try to build a binary for windows at least....maybe John33
The source code link is broken, it's: https://helixcommunity.org/viewcvs/cgi/view.../codec/encoder/ (https://helixcommunity.org/viewcvs/cgi/viewcvs.cgi/datatype/mp3/codec/encoder/)
I'll look at it, but there doesn't seem to be a simple d/l or anonymous CVS access, as yet, so it looks like grabbing a file at a time!!
What's RPSL/RCSL license, briefly?
You can d/l the doc and the source (including the RPSL licence text) from: http://homepage.ntlworld.com/jfe1205/helix_mp3enc.zip (http://homepage.ntlworld.com/jfe1205/helix_mp3enc.zip)
I've not attempted any kind of build, as yet, this is just copied from the Helix CVS.
The source code link is broken, it's: https://helixcommunity.org/viewcvs/cgi/view.../codec/encoder/ (https://helixcommunity.org/viewcvs/cgi/viewcvs.cgi/datatype/mp3/codec/encoder/)
I'll look at it, but there doesn't seem to be a simple d/l or anonymous CVS access, as yet, so it looks like grabbing a file at a time!!
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=313225")
You need a free registration at helixcommunity.org to be able to acces their cvs server. More information: [a href="https://common.helixcommunity.org/2004/devdocs/quickstart]https://common.helixcommunity.org/2004/devdocs/quickstart[/url]
I beg one of my friend to compile a windows binary of this mp3 coder for me, and here it is:
http://www.hydrogenaudio.org/forums/index....showtopic=35540 (http://www.hydrogenaudio.org/forums/index.php?showtopic=35540)
Hope someone with good ear can evaluate this coder.
I could add this encoder in my next tests
I could make it work, but unfortunately I haven't found yet the magic formula to use it directly with foobar2000. Help would be appreciated For batch encodings (with PCM source only), I'm using Speek's Wav2Gogo (http://members.home.nl/w.speek/download/Wav2Gogo.exe) (mp3enc.exe must be renamed as gogo.exe).
This encoder have a nice VBR scale (from 0 to 150).
Some points are obscure to me:
mode Select encoding mode: mode-0 stereo=0 mode-1 stereo=1 dual=2 mono=3.
nsbstereo
Applies to mode-1 stereo mode only. Number of subbands to
encode in independent stereo. Valid values are 4, 8, 12, and 16.
The encoder limits choices to valid values. The encoder
will make a default selection if nsbstereo = -1.
Valid values for Layer III are 3-32.
filter_select
Selects input filtering: no filter = 0, DC blocking
filter = 1.
I'd say that quality is (clearly) inferior to LAME but speed could make this encoder more attractive.
I could add this encoder in my next tests
Thank you guru.
I'd say that quality is (clearly) inferior to LAME but speed could make this encoder more attractive.
[a href="index.php?act=findpost&pid=313307"][{POST_SNAPBACK}][/a]
I don't know all the options neither.
This coder is not considered stronger than LAME, but I'm afraid a lot of people want to know how good it can be.
As for the speed, a asm-enabled compile may be more faster (this compile didn't use asm code).
At the other forum they asked if this was the Xing encoder. Since it was Karl Lillevold who announced it, it may well be the case. Does anybody know? I couldn't open the .zip file and try it out.
At the other forum they asked if this was the Xing encoder. Since it was Karl Lillevold who announced it, it may well be the case. Does anybody know? I couldn't open the .zip file and try it out.[a href="index.php?act=findpost&pid=313309"][{POST_SNAPBACK}][/a]
Better wait to hear it from Karl himself. I couldn't see any XING headers in the sources, but considering the big amount of assembly code in there, I would suppose it is.
I'm trying to compile it with ASM, but they don't even mention what assembler you should be using! Hopefully it's MASM...
DigitalDictator, I have tried to download it @ HA with success. Your problem may be solved by clear the cache of your browser.
As we all know, Real bought Xing's mp3 encoder, so this coder have great possibility to be right the Real tweaked Xing. But this question is supposed to be answered by Karl himself.
The VBR mode sounds interesting. I've encoded 35 samples (from Roberto's listening tests) with -V50, and average bitrate was ~127 kbps (but with huge difference between samples). Quality was very interesting (forgot my previous comment about relative quality compared to LAME: serious testing is needed), and I'd say that it should be wise to give at least a try to this encoder.
About VBR and bitrate, it seems that some software have problems to calculate the bitrate. foobar2000 for example evaluate the bitrate at 80 kbps for each samples ?? MisterQuestionMan is also fooled. Only Encspot gives me reliable (I suppose) results. Also funny to see encspot detect three different encoders :
- Gogo (> 3.0) most often
- Lame (old) or m3e
- Xing (new)
http://foobar2000.net/divers/temp/RealEncspot.html (http://foobar2000.net/divers/temp/RealEncspot.html)
http://foobar2000.net/divers/temp/RealMQM.html (http://foobar2000.net/divers/temp/RealMQM.html)
About VBR and bitrate, it seems that some software have problems to calculate the bitrate. foobar2000 for example evaluate the bitrate at 80 kbps for each samples ?? MisterQuestionMan is also fooled. Only Encspot gives me reliable (I suppose) results. Also funny to see encspot detect three different encoders :
- Gogo (> 3.0) most often
- Lame (old) or m3e
- Xing (new)
http://foobar2000.net/divers/temp/RealEncspot.html (http://foobar2000.net/divers/temp/RealEncspot.html)
http://foobar2000.net/divers/temp/RealMQM.html (http://foobar2000.net/divers/temp/RealMQM.html)
[a href="index.php?act=findpost&pid=313315"][{POST_SNAPBACK}][/a]
I also tried the vbr mode, after 'fix MP3 header' by foobar2000, the bitrate shows OK. This problem may due to the hush compile that cannot handle vbr-header right.
Note: The encoded mp3 is recognized as 'Xing (new)' by Encspot only when there's no short-block used.
I could make it work, but unfortunately I haven't found yet the magic formula to use it directly with foobar2000. Help would be appreciated
Parameters: %s %d -V50
Highest BPS mode supported: 16
The BPS had me beat for a while.
Just tried with my collection of 150 samples. Average bitrate for -V50 setting is 122 kbps. Lowest bitrate happened with sample S26 (http://guruboolez.free.fr/SINGLE/S26_KEYBOARD_Piano_D.ofr) (66 kbps) and highest one with sample A03 (http://guruboolez.free.fr/ARTIFICIAL/A03_emese.ofr) (250 kbps). Wow! That's VBR ! This last sample is now detected by Encspot as a Fhg (fastenc) source
Anyway, this sample proves if needed that a short-block switching algorithm is present, and is working:
long block = 15,2%
short block = 84,8% !!
I'm typing this message while listening the 150 samples, and the output gallery is far from being crappy. Some samples sound bad (solo harpsichord, percussions) but in average the encoder seems to be useable at this bitrate (not for archiving of course). I'm currently on my notebook I my judgment could be fooled by the poor output of the AC97 component; but on a weak DAP situation is not different.
Ah... I'm listening to piano, and pre-echo could also be annoying (S27 (http://guruboolez.free.fr/SINGLE/S27_KEYBOARD_Piano_E.ofr) - S36 marimba too (http://guruboolez.free.fr/SINGLE/S36_OTHERS_Marimbas_A.ofr)). Ringing on S30 (http://guruboolez.free.fr/SINGLE/S30_OTHERS_Accordion_A.ofr)...
Well, it's MP3 at 123 kbps on average
Parameters: %s %d -V50
Highest BPS mode supported: 16
The BPS had me beat for a while.
It works fine now, thanks a lot!
Edit: sorry, it seems there's no need to recompile for now
I also tried the vbr mode, after 'fix MP3 header' by foobar2000, the bitrate shows OK. This problem may due to the hush compile that cannot handle vbr-header right.
Solution: Just add -X or -X2 to the commandline to solve the problem.
From mp3enc.exe -Help:
X MPEG compatable Xing header, -X2 with/TOC
Yeah. Parameter should be "Parameters: %s %d -V50 -X" to get correct vbr-header.
Tomorrow, there will be a asm-enabled binary available.
I found a bug:
-V0 -X => no XING header
-V0 -X2 => no XING header
-V0 with 150 classical samples => 96 kbps and therefore could potentially be used in my next test with this group of sample.
[this is (almost) copied from my reply on doom9]:
If someone were to contribute standalone makefiles, or bugfixes, especially ones that on Win32 will include the i386 asm code, I am sure that would be most appreciated. I can check them into CVS (after a code review on the proper Helix mailing list).
Yes, this is based on the (infamous) Xing encoder, but it has been much improved from its early days, and does not suffer from the well known problems it had. This encoder was never included in any stand-alone Win32 Xing encoder app, but has been shipping with RealPlayer for a few years.
AFAIK, after these improvements, it was also licensed to a large h/w electronics manufacturer who chose it after extensive quality tests.
New compile with asm enabled and several bug-fixes.
Please check.
http://www.hydrogenaudio.org/forums/index....64&#entry313464 (http://www.hydrogenaudio.org/forums/index.php?showtopic=35540&st=0&p=313464&#entry313464)
Please check.
Youp, -V0 -X is fixed on my side.
I don't know what kind of miracle the asm compile could do, but encoding speed is now much faster! Thanks for this update
Once again, a way more readable source code than Lame.
To me this is very interesting, in the same category as the 3gpp AAC encoder.
when (if) the quality of the encoder has been checked out, would it be possible to "borrow" some ideas and implement them into LAME? Or maybe vice versa? If, as Gabriel states, the code is much more simple to understand?
I have the same kind of question. Can this encoder be improved based on that wierd license.
For LAME, I'm sure 4.x series will be much readable than current branch.
I'm trying to compile it with ASM, but they don't even mention what assembler you should be using! Hopefully it's MASM...
All but "pow34.asm" can be compiled with MASM. The last binary I upload didn't use this asm.
I'll upload the third compile with "pow34.asm" used (use the .obj file from cvs to link).
Edit: the third compile upload down.
when (if) the quality of the encoder has been checked out, would it be possible to "borrow" some ideas and implement them into LAME? Or maybe vice versa? If, as Gabriel states, the code is much more simple to understand?[a href="index.php?act=findpost&pid=313546"][{POST_SNAPBACK}][/a]
The licenses are conflicting.
Licenses can't prevent you from borrow ideas.
Patents do that.
The project file for compilation uploaded.
There's 2 files modified by CML, who compiled it. It's "tomp3.cpp" and "xhead.c"
You can download it here:
http://www.hydrogenaudio.org/forums/index....showtopic=35540 (http://www.hydrogenaudio.org/forums/index.php?showtopic=35540)
Licenses can't prevent you from borrow ideas.
Patents do that.
[a href="index.php?act=findpost&pid=313611"][{POST_SNAPBACK}][/a]
True. One doesn't have to copypaste anyone's code, he can just write the same thing by himself.
when (if) the quality of the encoder has been checked out, would it be possible to "borrow" some ideas and implement them into LAME? Or maybe vice versa? If, as Gabriel states, the code is much more simple to understand?
Well, if there are good ideas, perhaps they will also be used in Lame. However, please note that the Real encoder is way simpler than Lame, and its quality is probaly lower than the Lame one (but it should still be a overall good encoder).
Regarding implementing stuff from Lame into Real's encoder, I am wondering why would anyone do that, except people from Real. Remember that Real's encoder, while beeing open source (ie source are available) is still Real's full property.
However I like seeing clean audio encoders that work well, this is refreshing fo me.
I was surprised at the encoding speed of Helix MP3 encoder and made a comparison with other MP3 (and some codecs for reference) encoders in 128kbps range. Helix VBR mode (with ASM enabled) is really fast and impressive. IMHO the sound quality of -V75, which gives roughly 128kbps, is even better than F-IIS CBR 128kbps (no detailed comparison done, sorry). Quality comparison with Gogo3.13a -b128 might be interesting for impatient users.
) since it's 20% faster (according to Takehiro).
EDIT3: I added the results for Helix MP3 encoder with "-U2" option enabled. Now "gogo 3.13a -b128" and "mp3enc -V75 -X2 -U2" are tied in terms of encoding speed.
Insane speeds indeed.
And I'm amazed that so many encoders are faster than MPC. I had never seen a comparison like that.
Does those results use the new faster compile of mppenc 1.15v
Does those results use the new faster compile of mppenc 1.15v
[a href="index.php?act=findpost&pid=313764"][{POST_SNAPBACK}][/a]
Yeah, I downloaded mppenc yesterday from musepack.net .
I was surprised at the encoding speed of Helix MP3 encoder [...]
[a href="index.php?act=findpost&pid=313747"][{POST_SNAPBACK}][/a]
Since Helix MP3 encoder is based on Xing version 2, and that encoder performed 8x faster than the encoders of that time (at least that was the slogan), I don't see this as much as a surprise, but as a confirmation of the source, and a good job at maintaining the efficiency when improving the encoder.
It performed almost realtime (or maybe a bit faster) in a P-133 while LAME of that time ( 3.20? 3.40? can' remember) took around 20 minutes for a 4 minute song in the same machine.
On the other side, nice graph. Now, as you say, the interesting thing is the ABX test against gogo
nyaochi,
Did you try the latest binary? For my PC Helix MP3 Encoder is the fastest.
WAV 45:23
Helix MP3 Encoder 0:37
GOGO 3.13 1:52
Ogg Lancer 1:56
MPC 1.15v 2:27
FAAC 1.24.1 4:16
Lame 3.97a10 4:45
Nero 3.2.0.7 6:11
WinXP SP2, AMD Sempron 2400+, 512mb ram
Did you try the latest binary? For my PC Helix MP3 Encoder is the fastest.
[a href="index.php?act=findpost&pid=313960"][{POST_SNAPBACK}][/a]
Yes, the third version as I wrote in the list of encoders. I have no idea why Gogo is so slow on your machine, but the other figures look reasonable to me.
Regarding implementing stuff from Lame into Real's encoder, I am wondering why would anyone do that, except people from Real. Remember that Real's encoder, while beeing open source (ie source are available) is still Real's full property.
Naw... I don't know if I want that really... I must say I'm totally lost when it comes to licences and patents. You say it's open source but still full property of Real's? So, can the encoder be forked? Are third party allowed to tune it? Or do you have to ask Real before you release a tweaked version? Are they still working on it?
I tried it out and the speed is jaw dropping. I will try to ABX it at around 128 kbps. I totally suck at ABXing but I'll give it a try.
Everybody,
Helix mp3 encoder can be even faster when use -U2 switch, which include optimization for P3 (SSE?).
With all these speed optimization, the output MP3 file are not bit-identical. But it may not suffer the quality much (someone can explain if this statement is true?).
Edit: some error corrections
New project uploaded. Code cleaned and all asm can be compiled by MASM now.
Thanks for all your tweaking, compiling, and testing. I will download the latest exe and try it out myself I have to admit, this is much more feedback than I had ever expected when I announced the release on doom9. I was going to announce on hydrogenaudio too, but kurtnoise beat me to it ...
Thanks for all your tweaking, compiling, and testing. I will download the latest exe and try it out myself I have to admit, this is much more feedback than I had ever expected when I announced the release on doom9. I was going to announce on hydrogenaudio too, but kurtnoise beat me to it ...
[a href="index.php?act=findpost&pid=313992"][{POST_SNAPBACK}][/a]
All these works are due to my friend CML, who do all these tweaking, compiling, and testing.
I'll thank you, karl_lillevold. You bring us this good mp3 encoder.
Now we all are expecting for guruboolez's next test report on lossy codecs @ 96k.
About my next test: few words to say that I'm currently in holidays, and I can't consequently work for my test. Don't expect anything before 2 weeks I'd say
~16 seconds for a 5:18 Minutes track on my old Intel PIII500 with "-V90 -X -U2" this is a ratio of almost tracktime/20! With Lame vbr-new I have somewhere between 3-4 and 2 in old vbr mode.
There's some 'hidden' switches to play with this encoder. But some of them don't even have notes in the source code.
For example, there's a '-tx', default is 8, later altered to 6. With larger -tx, the produced file became bigger. Can someone tell me what the hell this switch down?
The correspond source is in bitallo3.cpp, line which contain
f = ba_control.test1;
And I wonder if there's something can do with the lowpass frequency. Default lowpass never exceed 16k Hz.
Maybe Karl Lillevold can tell us a little bit more about those switches, e.g. -U2, what happens with the quality when you add it? Are there any switches that bring down the speed but increase the quality?
Helix mp3 encoder windows binary rev4 uploaded.
This version has more detailed switch description with -Help
Edit: This rev5 has no restriction to -hf switch.
As of the quality with high frequencies encoded, can someone with good hearing do some listening tests?
rev6 uploaded.
-HF description added and will not take effect when bitrate/channle less than 96k or vbr_scale less than 80, as default.
-F to set lowpass frequency
Enig123: Does this CLI encoder allow std input / output piping?
Sorry. I'm afraid there's no pipe supporting for now.
Can someone give some link thant can indicate how to add such features?
/Edit: removed irrelevant text.
It should be straigth forward to replace the opening of the wave file with opening the stdin instead. Modify opening of wav file in src\test\tomp3.cpp to something like:
/*
* open the input wave file
*/
if (strcmp(filename, "-") == 0) {
handle = fileno(stdin);
setmode(handle, O_BINARY);
} else
handle = open ( filename, O_RDONLY | O_BINARY );
if ( handle < 0 )
{
printf ( "\n CANNOT_OPEN_INPUT_FILE" );
goto abort;
}
And similarly for the output file:
/*
* create the MPEG output file
*/
if (strcmp(fileout, "-") == 0) {
handout = fileno(stdout);
setmode(handout, O_BINARY /* | .... ? */);
} else
handout =
open ( fileout, O_RDWR | O_BINARY | O_CREAT | O_TRUNC,
S_IREAD | S_IWRITE );
if ( handout < 0 )
{
printf ( "\n CANNOT CREATE OUTPUT FILE" );
goto abort;
}
Add: You must also modify the CL processing:
/****** process command line args */
for ( k = 0, i = 1; i < argc; i++ )
{
if ( argv[i][0] != '-' || argv[i][1] == '\0' ) // <-- add this
{
if ( k == 0 )
filename = argv[i];
if ( k == 1 )
fileout = argv[i];
k++;
continue;
}
Thanks for making these improvements and builds. Is there any chance you might consider contributing your improvements back to the Helix Community?
rev6 uploaded.
-HF description added and will not take effect when bitrate/channle less than 96k or vbr_scale less than 80, as default.
-F to set lowpass frequency
[a href="index.php?act=findpost&pid=314289"][{POST_SNAPBACK}][/a]
Karl,
I've asked CML for this. He's willing to, after some cleaning work.
All these switches are in the sourcecode already, we did no more than just finding it.
Regards,
It seems there's a problem encoding PCM 22050khz & 11025khz files.
All other sample rates work ok from 8000khz to 48000khz.
I've tried PCM files with different bitdepths & mono/stereo settings and all is fine
except with those two sample rates, mp3enc just closes with an error.
Nyaochi's speed test has been updated (-U2 switch tested)
http://nyaochi.sakura.ne.jp/xoops/ (http://nyaochi.sakura.ne.jp/xoops/)
cli with piping has been uploaded.
@Raffles
There's nothing I and CML can do for this bug. After the latest project & source files been released, I hope someone can take a look at it and help with this kown bug.
Rev 7 is out : command line piping support added.
http://www.hydrogenaudio.org/forums/index....ndpost&p=314509 (http://www.hydrogenaudio.org/forums/index.php?showtopic=35540&view=findpost&p=314509)
A few quirks:
1. You are trying to get the size of the stdin stream (for showing percentage). Only works for: mp3enc stdin < file.wav, but not for: cat file.wav | mp3enc stdin
In this case you'll divide by zero when computing percentage.
2. Only stdin is supported - not stdout. You should print all text output to stderr, then apply the suggested code above.
Btw: isn't it better with "-" for stdin / stdout as in most other apps (including lame)? The above code I supplied used that.
Add:
3. It is spelled "Usage", not useage.
tycho,
If you can do something with that, I'll be appriciated. The latest source have been uploaded. The corrected file (maby by you) can be uploaded in the same threat.
At least it can cooporate fine with foobar2000 for now. My friend CML, who did these tweaks, was not very familiar in this area and have done enough for him.
handle = fileno(stdin);
[a href="index.php?act=findpost&pid=314327"][{POST_SNAPBACK}][/a]
On most UNIX systems STDIN_FILENO will do the trick. I never developed on Windows, but it's probably defined there as well
A few quirks:
1. You are trying to get the size of the stdin stream (for showing percentage). Only works for: mp3enc stdin < file.wav, but not for: cat file.wav | mp3enc stdin
In this case you'll divide by zero when computing percentage.
[a href="index.php?act=findpost&pid=314537"][{POST_SNAPBACK}][/a]
For recording live stream over STDIO it is good to support 0 length files (ie unknown) and just keep writing until data stops.
@enig123: Sorry, I'm off on vacation, so no more time to play with this now.
@spoon: I simply meant that the display of percentage should be removed when file length is unknown.
About compiling with VC6:
I converted the VC71 proj to VC6 with http://www.codeproject.com/tools/prjconverter.asp (http://www.codeproject.com/tools/prjconverter.asp) You only need to add the main tomp3.cpp, I think.
/Edited wrong info:
Speed: You must install VC6 with SP5, and the VC6 processor pack. VC6 SP6 does not support the processor pack, which supports SSE/SSE2 and 3DNow! instruction sets. With this you'll get the same speed as with VC71.
rev8 binary uploaded.
Changelog
1) support stdout now
2) using "-" instead of "stdin" with previous rev7
You can do test with
mp3enc - - < 001.wav > 001.mp3
Use command like
- %d -V75 -X -U2
to use with foobar2000.
@tycho
Thank for your VC6 project file (rjamorim will love this ).
CML was kind enough to continue his tweaking with this coder.
Nyaochi's speed test has been updated (-U2 switch tested)
http://nyaochi.sakura.ne.jp/xoops/ (http://nyaochi.sakura.ne.jp/xoops/)
I updated the graph in this thread. Now "gogo 3.13a -b128" and "mp3enc -V75 -X2 -U2" are tied
I couldn't resist, and after some hesitations, I started the 96 kbps with the first pool dedicated to MP3. I did it on a different computer with poorer components (AC'97). Notation will therefore be less severe (poorer hardware -> less audible problems).
The choice of settings for each encoder was difficult. I tried to obtain an average bitrate comprise between 96 kbps (CBR) and 100 kbps. The tolerence is much restrictive than the ±1O% fixed for my 80 kbps test. iTunes and Fh.IIS 'Audition' are nevertheless out of range for the second group of samples (104 kbps for iTunes / 102 for Fh.IIS), but the deviation is still inferior than 10% of the targeted bitrate (96 kbps).
tested encoders•
Fraunhofer, in
Adobe Audition v1.5group1 (classical) - VBR Q20 - Current: best quality - default: Joint Stereo + Intensity Stereo + 14440 Hz lowpass
group2 (various) - VBR Q30 - Current: best quality - default: Joint Stereo + Intensity Stereo + 14780 Hz lowpass
•
Fraunhofer, in
Windows Media Player 10 (ACM PRO version, 3.3.2.44) © 2004 Fraunhofer IIS
CBR: -b128
•
Apple iTunes 4.9.0.19VBR: 96 kbps Highest (default settings)
•
LAME 3.97 alpha 11ABR: --abr 101
•
Real mp3enc V5.0 rev.6VBR: -V20
calculated bitrate (short samples library)• Fh.IIS 'Audition'
- classical (185 samples) = 96 kbps
- various (35 samples) = 102 kbps
• Fh.IIS 'ACM encoder'
- classical (185 samples) = 96 kbps
- various (35 samples) = 96 kbps
• iTunes
- classical (185 samples) = 100 kbps
- various (35 samples) = 104 kbps
• LAME
- classical (185 samples) = 98 kbps
- various (35 samples) = 100 kbps
• REAL
- classical (185 samples) = 100 kbps
- various (35 samples) = 100 kbps
hardware and software settings• Compaq Presario 2100 series; AC'97 'soundcard'; poor line_out
• Philips SBC HP910 headphones
• ABC/HR software (ff123)
• files decoded with foobar2000: resampling at 48 KHz & ReplayGain track mode enabled; offset corrected for LAME and Fh.IIS ACM encodings.
tested samples• 40 samples, including
- 15 samples of 'various music'
- 25 samples of 'classical music'
(the selection is exactly the same than for my 80 kbps listening test pools.
RESULTS Fh.IIS Fh.IIS iTunes LAME Real
Audit. ACM PRO v.49017 3.97a11 5.0 rev.6
A02_metamorphose 3.5 2.0 1.0 3.2 2.7
E06_MODERN_CHAMB 4.2 2.0 2.3 4.2 2.5
E15_MODERN_CHAMB 2.5 2.0 4.0 5.0 2.3
E22_MODERN_ORCHE 3.4 2.0 3.8 4.2 2.8
E26_MODERN_ORCHE 2.0 1.5 3.5 4.0 3.0
E31_PERIOD_CHAMB 4.5 1.3 3.0 4.0 2.0
E40_PERIOD_CHAMB 1.8 3.0 1.5 4.0 3.5
E51_PERIOD_ORCHE 3.0 2.5 1.0 4.2 1.5
E53_PERIOD_ORCHE 2.7 2.0 1.7 3.2 2.9
S03_BOW_Cello_C 2.3 2.5 2.0 4.0 3.0
S08_BOW_Violin_B 3.5 2.0 3.0 4.2 3.5
S12_KEYBOARD_Har 2.8 2.0 2.2 2.5 1.5
S17_KEYBOARD_Org 2.0 1.5 2.5 3.7 2.5
S27_KEYBOARD_Pia 2.5 2.0 3.0 4.5 2.0
S38_PINCH_Guitar 2.0 2.5 4.0 4.3 3.5
S50_WIND_Flute_B 2.5 2.0 3.5 3.0 4.5
S54_WIND_Trombon 3.3 1.8 1.5 3.6 2.5
V02_CHORUS_Child 1.2 1.7 2.0 3.5 2.5
V07_CHORUS_Mixed 2.8 2.0 1.7 4.2 1.5
V10_DUET_Males_A 2.0 2.4 2.8 3.5 3.2
V15_PLAINCHANT_M 2.0 2.5 3.0 3.4 2.3
V19_SOLOIST_Fema 2.0 1.8 3.1 4.5 2.6
V20_SOLOIST_Fema 3.2 2.0 1.5 3.5 2.7
V24_SOLOIST_Male 3.0 2.5 2.0 3.0 2.8
V27_SOLOIST_Male 2.8 2.5 2.5 3.5 2.3
25 CLASSICAL: MEAN 2.70 2.08 2.48 3.80 2.64
41_30sec 2.3 2.0 1.0 3.0 3.0
ATrain 2.5 2.0 1.3 3.5 2.5
DaFunk 3.2 2.0 1.8 3.5 1.5
death2 2.8 2.0 1.0 2.5 2.7
EnolaGay 2.8 2.2 2.6 2.8 2.4
experiencia 3.2 2.2 3.4 3.6 2.7
getiton 2.8 1.5 2.7 3.5 2.0
kraftwerk 1.5 1.5 2.5 1.5 3.5
LifeShatters 3.5 2.5 1.5 4.0 2.0
NewYorkCity 3.5 2.2 1.5 3.5 3.0
OrdinaryWorld 3.7 2.5 2.5 4.0 1.5
Quizas 2.4 2.0 1.3 3.8 2.6
rosemary 2.5 2.0 1.5 4.0 3.5
SinceAlways 2.5 2.2 3.0 2.7 2.0
trust 3.5 2.0 1.0 4.2 1.5
15 VARIOUS SAMPLE: MEAN 2.85 2.05 1.91 3.34 2.43
40 SAMPLES: MEAN 2.76 2.07 2.27 3.63 2.56
Fh.IIS Fh.IIS iTunes LAME Real
Audit. ACM PRO v.49017 3.97a11 5.0 rev.6
FRIEDMAN version 1.24 (Jan 17, 2002) [url=http://ff123.net/]http://ff123.net/[/url]
Tukey HSD analysis
Number of listeners: 40
Critical significance: 0.05
Tukey's HSD: 0.423
Means:
LAME Fh.Aud Real iTunes Fh.acm
3.62 2.76 2.56 2.27 2.07
-------------------------- Difference Matrix --------------------------
Fh.Aud Real iTunes Fh.acm
LAME 0.870* 1.062* 1.357* 1.555*
Fh.Aud 0.193 0.488* 0.685*
Real 0.295 0.492*
iTunes 0.197
-----------------------------------------------------------------------
LAME is better than Fh.Aud, Real, iTunes, Fh.acm
Fh.Aud is better than iTunes, Fh.acm
Real is better than Fh.acm
<<< PLOTS >>> (http://www.hydrogenaudio.org/forums/index.php?act=Attach&type=post&id=1654)
CONCLUSIONS• Fh.IIS 'ACM': this encoding suffers from a severe lowpass (~12KHz), the worse from all encodings tested here. For that reason, I hesitated to feature this encoder. It's very hard for me to compare different encodings when such difference in lowpass exists. This encoder is therefore the easiest to detect; comparison with reference and even with other encodings is immediately shoking. Lowpass could bring one advantage: it often limits the amount of audible distortion. But here, the ACM encoder is really far from being free of artifacts and distortions. The encoder was convincing once or twice (E40, beginning of Death2), but disappointing most of time. Once the test finished, I noticed that this encoder obtained with regularity 2.0 as notation. In one word, this encoder was maybe handicap by the excessive lowpass, and may produce better results with ~14...~15 KHz lowpass (similar value than other encoders tested here).
• Fh.IIS 'Audition': As tester, I'd say that this encoder had the most annoying VBR mode. It was impossible for me to find a unique setting in order to obtain 96...100 kbps for both groups. CBR was not a solution: lowpass would be a big handicap (~11KHz vs ~14,5KHz). That's why I decided to use two different settings: Q20 for 'various' and Q30 for 'classical'.
Average results are similar for both groups, but it's important to note the variations within the classical group. VBR encoding is often difficult at low bitrate, and rarely provide constant quality (purpose of variable bitrate). Illustration here... With the second group, results are more constant and this encoder clearly appears as one of the best MP3 encoder (with LAME).
• iTunes: highest bitrate and poorer quality... at least with the second group of sample. Quality is unlistenable to my ears, with very annoying distortions. The poor quality is maybe a consequence of the generous lowpass, probably excessive for this bitrate. Result are better with classical (encoding difficulty is also lower...).
• LAME 3.97a11: The best for both groups, and high results with classical music. It simply means that quality reached by LAME at 96 kbps is suitable on poor/average listening conditions (with some exceptions of course: bad notations on kraftwerk, SinceAlways or harpsichord), especially with classical. Another point: LAME is the only encoder which automatically resample to 32 KHz. The choice is a very pertinent one in my opinion.
• Real mp3enc V5.0 rev.6: mixed feelings for this encoder. Quality is not comparable to LAME's performance, similar but slightly inferior to Fh.IIS 'Audition' (in any case prohibitive) and also superior to iTunes of Fh.IIS 'ACM'. But if we take into consideration the encoding speed, the performances are much more enjoying. This encoder is 4 or 5 time faster than LAME, and I'm pretty sure that the quality could easily be improved by resampling the output to 32 KHz (any user could do it with foobar2000 for instance, but I recall that my test consists of testing various MP3 encoding solutions with default settings).
This MP3 pool was interesting.
- First, it reveals that Fraunhofer encoders are far from being superior to LAME at bitrate < 100 kbps. In fact, LAME is obviously better with most samples I've tested here.
- Second: iTunes reveals another time severe flaws. I know that Roberto still regrets bad choice made for his MP3 test (iTunes was tested with lower bitrate than other contenders). But here, even with few additional kbps iTunes MP3 appears as a poor encoding solution, especially with 'various music'. Obviously, iTunes MP3 doesn't need to be handicapped by wrong setting to finish last...
- Third: ultra-fast encodings doesn't necessary ruin the encoding quality. REAL (ex-XING) illustrate it. Acceptable quality is possible, even with VBR at low bitrate, even with Turbo enabled.
EDIT: many thanks to Enig123 for his work
- Third: ultra-fast encodings doesn't necessary ruin the encoding quality. REAL (ex-XING) illustrate it. Acceptable quality is possible, even with VBR at low bitrate, even with Turbo enabled.[a href="index.php?act=findpost&pid=314613"][{POST_SNAPBACK}][/a]
Great. Another proof that Xing isn't as bad as people used to depict it.
Thanks for the test, Guruboolez
I'm quite curious how far this encoder can go in the mid-high bitrate range. Especially with the hidden -HF2 -Fxxxx combination, which make it possible to encode high frequency signal (>16KHz), I wonder if it can do good to the sound quality or not.
rev9 uploaded
many small tweaks
add -EC switch to display more information
rev9 uploaded
Enig, thanks for your effort, but would you please
a) offer urls here
b) leave the file names as they were, you name the binary "hmp3.exe" now and "mp3enc.exe" before... THX
rev9 uploaded
Enig, thanks for your effort, but would you please
a) offer urls here
b) leave the file names as they were, you name the binary "hmp3.exe" now and "mp3enc.exe" before... THX
[a href="index.php?act=findpost&pid=314903"][{POST_SNAPBACK}][/a]
It was me that changed the name of the executable simply so that it was distinguised from the 'cml' binary. If you wish to rename it, go ahead, it won't affect anything.
There's a CML compiled binary in the rev9 bundle, which can be downloaded from http://www.hydrogenaudio.org/forums/index....showtopic=35540 (http://www.hydrogenaudio.org/forums/index.php?showtopic=35540) .
I (easily) managed to compile the c(++) code in Linux and the bin works in a quick test. But is there an easy way to get the asm files converted to nasm style?
Enig123,
Many thanks for your work, this codec seems very interesting.
I found something that believe is important, and it is that the encoder eliminates some samples in the end of the file.
I noticed this problem with normal music; after I made a pure tone of 1 Khz with Cool Edit Pro (exactly 20.000 seconds) with not phase difference in both channels. After I encoded the file in -V150 -X2 setting.
I decoded the resultant mp3 file with Foobar2000 v0.8.3; and in CoolEdit Pro I eliminated the null samples in the beginning; the file didn't contain null samples in the end. The resultant decoded wav file has now 19.724 seconds.
I did the same procedure described previously but now with Winamp 5.092; the resultant decoded wav file has now 19.724 seconds; the same result that with Foobar.
Considering that Foobar and Winamp are excellent players, and, in addition, the results are the same, I believe that is a problem of the encoder, that probably may be eliminated. Lamentably, I cannot because I am not a programmer, but perhaps another person here may do it.
Regards,
I (easily) managed to compile the c(++) code in Linux and the bin works in a quick test. But is there an easy way to get the asm files converted to nasm style?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=314937")
intel2gas, 1.3.3, A converter between the NASM and GAS asm format (Intel/AT&T)
[a href="http://freshmeat.net/projects/intel2gas/]http://freshmeat.net/projects/intel2gas/[/url]
homepage:
http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/ (http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/)
CML's rev10
Length bug fixed, thank level
Comment: At first, I only wan't to make a compile of this encoder. Later on, it becomes work of a lot of tweaks, bug fixes and adding of new features.
So don't blame me much if I make you confused by frequent updates. I just want to help. It's another choice of available mp3 encoder with good speed. So you guys just enjoy encoding. You don't have to keep pace with all the minor updats because there's no quality improvement.
CML's rev10
1). Length bug fixed, thank level
Yes, this works now; thanks to you .
I (easily) managed to compile the c(++) code in Linux and the bin works in a quick test. But is there an easy way to get the asm files converted to nasm style?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=314937")
intel2gas, 1.3.3, A converter between the NASM and GAS asm format (Intel/AT&T)
[a href="http://freshmeat.net/projects/intel2gas/]http://freshmeat.net/projects/intel2gas/[/url]
homepage:
http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/ (http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/)
[a href="index.php?act=findpost&pid=315009"][{POST_SNAPBACK}][/a]
Maybe I haven't been too clear. I don't intend to use the inline assembler of gcc. Merely I want to use NASM, which is able to understand intel syntax. The problem is the assembler files are written for MASM (intel syntax, as well). It seems MASM uses (slightly?) different style than NASM, but as I am not a big assembler coder, I don't exactly know how to convert the files.
Converting the asm files to NASM would make the code a lot more portable (*hint* *hint*).
I (easily) managed to compile the c(++) code in Linux and the bin works in a quick test. But is there an easy way to get the asm files converted to nasm style?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=314937")
intel2gas, 1.3.3, A converter between the NASM and GAS asm format (Intel/AT&T)
[a href="http://freshmeat.net/projects/intel2gas/]http://freshmeat.net/projects/intel2gas/[/url]
homepage:
http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/ (http://www.niksula.cs.hut.fi/~mtiihone/intel2gas/)
[a href="index.php?act=findpost&pid=315009"][{POST_SNAPBACK}][/a]
Maybe I haven't been too clear. I don't intend to use the inline assembler of gcc. Merely I want to use NASM, which is able to understand intel syntax. The problem is the assembler files are written for MASM (intel syntax, as well). It seems MASM uses (slightly?) different style than NASM, but as I am not a big assembler coder, I don't exactly know how to convert the files.
Converting the asm files to NASM would make the code a lot more portable (*hint* *hint*).
[a href="index.php?act=findpost&pid=315051"][{POST_SNAPBACK}][/a]
intel2gas actually works both ways, but it will only compile under **nix. There isn't a win32 binary that I could find.
I believe I have found the answer to the problem regarding the encoding of 11025Hz and 22050Hz samples. The problem is in the default setting on line #204 of
tomp3.cpp:
// mpeg_select = 0;
mpeg_select = 1; // default to mpeg1
XingHeadFlag = 0;
/****** process command line args */
By changing the default, as above, all sample rates seem to encode quite happily, with upsampling working as I believe was intended.
[/code] By changing the default, as above, all sample rates seem to encode quite happily, with upsampling working as I believe was intended.
[a href="index.php?act=findpost&pid=315186"][{POST_SNAPBACK}][/a]
Is there a way not to upsample, just output 22050/11025 Hz mp3?
With the patch below, the code compiles fine on Mac OS X using 'gcc -O3 -lstdc++ -o ../hmp3-mac -Ipub **/*.c **/*.cpp'. Didn't actually test it, though
diff -Naur --exclude hmp3-mac ../helix_mp3enc_cml10/src/test/tomp3.cpp ./src/test/tomp3.cpp
--- ../helix_mp3enc_cml10/src/test/tomp3.cpp 2005-07-21 21:23:08.000000000 +0000
+++ ./src/test/tomp3.cpp 2005-07-22 03:31:22.000000000 +0000
@@ -487,7 +487,9 @@
if(strcmp(filename,"-")==0)
{
handle=stdin;
+#ifdef _WIN32
setmode( fileno( handle ), O_BINARY );
+#endif
}
else
handle = fopen ( filename, "rb" );
@@ -547,7 +549,9 @@
if(strcmp(fileout,"-")==0)
{
handout=stdout;
+#ifdef _WIN32
setmode( fileno( handout ), O_BINARY );
+#endif
}
else
handout = fopen ( fileout, "w+b" );
I've been googling around for something you can use.
http://www.blah.ch/att2intel/ (http://www.blah.ch/att2intel/)
Converts ASM code in AT&T syntax (GNU Assembler) to Intel syntax (TASM, NASM & Co.).
http://membres.lycos.fr/placr/a2i.html (http://membres.lycos.fr/placr/a2i.html)
A2I is an utility which can translate assembly files in AT&T syntax (.S files produces by gcc for example) to NASM syntax. Dos binaries available.
http://www.bumba.net/~hmaon/a2i/ (http://www.bumba.net/~hmaon/a2i/)
Att2Intl will convert gcc's AT&T syntax assembly output (.s) into Intel syntax (.asm), intended for compilation with NASM or Tasm.
m2nasm: A perl script that handles some of the tedious parts of masm to nasm translation. Remember to always check the output.
internet archive, newest version:
http://web.archive.org/web/20030216031517/...lf99/m2nasm.txt (http://web.archive.org/web/20030216031517/http://users.otenet.gr/~alf99/m2nasm.txt)
# Masm to nasm translation attempt
# still at an early stage...
# 28/06/2002, written by Alexandros Frantzis
# alf82@freemail.gr
# usage: m2nasm.pl < input_file > output_file
I haven't used any of these, hope one of them works,
Further, the first bitrate it the overall average bitrate, whereas the second bitrate is the current bitrate, correct?
It should mean
frames: 1281, bytes in: 5902848( 47%), bytes out: 990509, br 243.81 236.95
and the first br is current bitrate, second is averaged bitrate.
By changing the default, as above, all sample rates seem to encode quite happily, with upsampling working as I believe was intended.
[a href="index.php?act=findpost&pid=315186"][{POST_SNAPBACK}][/a]
Is there a way not to upsample, just output 22050/11025 Hz mp3?
[a href="index.php?act=findpost&pid=315233"][{POST_SNAPBACK}][/a]
For low sample rates, it would appear that upsampling is the way the encoder is written to function.
In the file
mp3enc.cpp, function
MP3_audio_encode_init, lines 2691 - 2737, the encoding sample rate is determined according to 'mpeg' output type. Sample rate output below 16000Hz is not supported and input is upsampled. If the default switch is left as 0, then the 11025 input is upsampled to 22050 and is passed to the function
L3_audio_encode_vbr_MPEG2. The 11025 and 22050 inputs fail in this function within the principal loop contained therein. It also fails at CBR with these sample rates.
By setting the default switch to 1 (mpeg 1 layer III), the 11025 and 22050 samples are upsampled to 44100 and processed correctly.
This is, therefore, a way of circumventing the problem, but does not resolve it.
I have established that the point at which the program falls over when using the the 0 default, referred to above is in the 'window' junction in sbt.c, sbt.asm and xsbt.asm.
To illustrate, in sbt.c:
void
window ( const float vbuf[] )
{
int i, j, k;
const float *si, *bx;
const float *coef;
float sum1, sum2;
/*-- output to dct ping-pong buf b --*/
si = vbuf + 16;
bx = vbuf + 15;
k = 0;
coef = wincoef;
/*-- first 1 --*/
sum1 = 0.0f;
for ( j = 0; j < 512; j += 64 )
{
fprintf(stderr, "\nHere - window - before j");
sum1 += ( *coef++ ) * si[j];
fprintf(stderr, "\nHere - window - j = %d", j);
}
si++;
b[k++] = sum1;
/*-- 16 --*/
I added the fprintfs, they're not in the code!!
When the program is executed, the data loops through here once and on the second time through, the expression between the two fprintfs causes the crash. I fear to progress any further in this is beyond me!!
@Synaptic Line Noise
intel2gas doesn't like the files. m2nasm doesn't do anything here and I didn't try the others as they don't state they could to opposite direction (which I need).
I found this though:
http://www.programmersheaven.com/zone5/cat461/1349.htm (http://www.programmersheaven.com/zone5/cat461/1349.htm)
WINE can't hanlde this. (16bit exe?) So could someone alse try this? And then maybe run intel2gas over the result?
Yeah. CML have fixed the 22050 samplerate bug.
Now the latest version CML (r11 for now) be put on top of
http://www.hydrogenaudio.org/forums/index....t=0#entry313298 (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=35&t=35540&st=0#entry313298)
NOTE: This encoder only support mpeg-1&2, not 2.5, so it will never output mp3 with 11025 samplerate (22050 instead).
Yeah. CML have fixed the 22050 samplerate bug.
Now the latest version CML (r11 for now) be put on top of
http://www.hydrogenaudio.org/forums/index....t=0#entry313298 (http://www.hydrogenaudio.org/forums/index.php?act=ST&f=35&t=35540&st=0#entry313298)
NOTE: This encoder only support mpeg-1&2, not 2.5, so it will never output mp3 with 11025 samplerate (22050 instead).
[a href="index.php?act=findpost&pid=315453"][{POST_SNAPBACK}][/a]
Hmmm, the bug is obvious when you look in the right place, huh?!?!?
Hmmm, the bug is obvious when you look in the right place, huh?!?!?
Nope, there's really a crash bug with 22050 samplerate. After being fixed, this encoder can output mp3 with 22050 samplerate now, which belongs to mpeg-2.
You can check the sourcecode to verify this. There's a place typing "200" as "2100" in the original code.
There's a place typing "200" as "2100" in the original code.
[a href="index.php?act=findpost&pid=315484"][{POST_SNAPBACK}][/a]
That's what I was referring to.
As a newbie here, first let me congratulate everyone with the effort put in this coder.
It's been a ball watching everyone contribute.
Frequency analysis (cooledit) seems to show lowpass at approx 16 khz.
Can anyone confirm this as a general outcome ?
Is there an option in the code to change lowpass to something around 19-20 khz ?
Dirk.
Is there an option in the code to change lowpass to something around 19-20 khz?
See post #51 in this thread. It would appear that the -F switch now does this.
Regards,
Madrigal
Frequency analysis (cooledit) seems to show lowpass at approx 16 khz.
Can anyone confirm this as a general outcome ?
Is there an option in the code to change lowpass to something around 19-20 khz ?
Dirk.
[a href="index.php?act=findpost&pid=315580"][{POST_SNAPBACK}][/a]
Yeah. With -B >= 96 and -V >= 80, you can use -HF -F19000 or -HF2 -F19000 to achieve 19000 Hz lowpass.
Thanx guys. This setting just made my day.
Dirk.
I've added this post as a separate post here.
With this encoder, it's not very clear which number is what, in the progress text.
Please patch the program. I now know what what it's saying, but everytime I look at it still takes awhile to read it.
frames 1281 bytes in 5902848( 47%) bytes out 990509 br 243.81 236.95
This looks like "1281 bytes in" "5902848( 47%) bytes out "
Please add a LAME style progress text.
Frame | CPU time/estim | REAL time/estim | play/CPU | ETA
150/302 (50%)| 0:05/ 0:10| 0:05/ 0:10| 0.7506x| 0:05
-------------------------------------00:03-------------------------------------
kbps LR MS % long %
64.0 27.3 72.7 100.0
Especially since now we are just making cosmetic/interface changes.
Also in the latest ICL9 compile, doing a
"hmp3enc -help | more" command doesn't work anymore.
Similar to here:
http://www.hydrogenaudio.org/forums/lofive...php/t30160.html (http://www.hydrogenaudio.org/forums/lofiversion/index.php/t30160.html)
How does:
Frame/Bytes Processed |Bytes Written|Current Bitrate|Average Bitrate
---------------------------------------------------------------------
14184/65319788 (100%)| 7080630 | 31.85kbps | 152.89kbps
Compression Ratio 9.23:1
Elapsed time = 8.046secs Time per frame = 0.567msecs
grab you?
"hmp3enc -help | more" command doesn't work anymore.
If it sends it to stderr, you can usually do it like this:
> hmp3enc -help 2>&1 | more
n00b alert: I'm kind of lost in all this code. Can someone post a good commandline for VBR ~80kbps and ~128kbps?
thanks in advance
kindofblue
Hello everyone,
After a few tests with the encoder I have noticed that some of the files it created had a nasty DC burst near the end of the file that can be heard when played with either Foobar or Winamp. It has been confirmed by checking in an audio editor
(http://jules.inpuj.net/HA/dc_offset2.jpg)
The funny thing was that it was not happening with all the files I was feeding the encoder with. After having thought hard for bit I have realized that the lowest common denominator was that the files the encoder would add some DC burst to were the file created with FL Studio. This program adds some RIFF sub-chunk data to the files it creates("Created with FL Studio 5", or if you specify it when rendering it adds info that can be read by Sonic Foundry Acid).
I have then created some small clips in FL Studio to test with the encoder and each time the DC burst was here.
Knowing that the FLAC encoder removes the RIFF sub-chunk data when encoding the files, I have tried encoding the original file created in FL studio with the FLAC encoder(which indeed found RIFF sub-chunk data that it removed) and then decode it back to wav to try to feed the Helix encoder with the decoded FlAC file. It worked as I expected to, the encoded file had no DC click at the end.
(http://jules.inpuj.net/HA/no_dc_offset2.jpg)
My conclusion is that the encoder will produce a DC burst at the end of the file if the Wav file contains some RIFF sub-chunk data. I have tried with various settings, bitrates, HF encoding or not, VBR or CBR and it constantly happened no matter what when the RIFF sub-chunk data was present.
I would gladly provide the devs with files created containing RIFF sub-chunk data if needed.
J.
Out of curiosity I disassembled a gcc compiled object of cnt.c and compared that with the cnt.asm source. And I have the strogn impression, that in fact the assmbler files are not even compatible. My assembler knowledge is very limited, but see for yourself:
c code
BI
CountBits0 ( void *table, int ix[], int n )
{
BI bi;
bi.bits = bi.index = 0;
return bi;
}
assembler (intel syntax)
_CountBits0 proc public
;; null case, ixmax = 0
xor eax, eax
xor edx, edx
ret
_CountBits0 endp
disassembled (at&t syntax) + interleaved source
BI
CountBits0 ( void *table, int ix[], int n )
{
0: 8b 44 24 04 mov 0x4(%esp),%eax
BI bi;
bi.bits = bi.index = 0;
return bi;
4: c7 00 00 00 00 00 movl $0x0,(%eax)
a: c7 40 04 00 00 00 00 movl $0x0,0x4(%eax)
}
11: c2 04 00 ret $0x4
14: 8d b6 00 00 00 00 lea 0x0(%esi),%esi
1a: 8d bf 00 00 00 00 lea 0x0(%edi),%edi
The problem is that a structure (consisting of 2 ints) is returend and obviously windows/msvc++/masm has different convention than gcc. While the former expects the struct in eax and edx, gcc writes to mem, if I understand correctly. So the asm code seems to be really for windows only...
no, gcc uses eax:edx as intel....
no, gcc uses eax:edx as intel....
[a href="index.php?act=findpost&pid=316060"][{POST_SNAPBACK}][/a]
Uhm, could you explain to me where you see that in above disassembled code?
i can't see it...you're right
i just assumed that gnu does the right thing
broken dissembler
but the code also doesn't write to memory...if you mean the lea-instructions
they are useless but i must say that i'm not really familiar with at&t
*edit
i'm completly with stupid...yeah it seems that gnu returns the structure
over the stack. and msvc returns it through eax:edx because it knows
that its only 8-byte in size. didn't know that. you could use int64 anyway.
sorry
i'm completly with stupid...yeah it seems that gnu returns the structure
over the stack. and msvc returns it through eax:edx because it knows
that its only 8-byte in size. didn't know that. you could use int64 anyway.
sorry
[a href="index.php?act=findpost&pid=316068"][{POST_SNAPBACK}][/a]
Yes, I also thought of using "long long" (or union long long with the struct) as workaround, as this should have same behaviour in both worlds. Anybody? (BTW, I also have not a clue what those lea instruction are there for...)
How does: Frame/Bytes Processed |Bytes Written|Current Bitrate|Average Bitrate
---------------------------------------------------------------------
14184/65319788 (100%)| 7080630 | 31.85kbps | 152.89kbps
Compression Ratio 9.23:1
Elapsed time = 8.046secs Time per frame = 0.567msecs
grab you?
[a href="index.php?act=findpost&pid=315884"][{POST_SNAPBACK}][/a]
Jolly good sir!
How does: Frame/Bytes Processed |Bytes Written|Current Bitrate|Average Bitrate
---------------------------------------------------------------------
14184/65319788 (100%)| 7080630 | 31.85kbps | 152.89kbps
Compression Ratio 9.23:1
Elapsed time = 8.046secs Time per frame = 0.567msecs
grab you?
[a href="index.php?act=findpost&pid=315884"][{POST_SNAPBACK}][/a]
Jolly good sir!
[a href="index.php?act=findpost&pid=316106"][{POST_SNAPBACK}][/a]
I've now posted the version with the modifed user interface at Rarewares 'mp3' page. I've done a little more tidying up than just the above.
Some samples seem to get encoded incorrectly. Please see an example (AWE32_20SEC.wav) below. I tried different compiles of Rev11 (including the latest Rareware version), but the results were the same.
Command-line used:
hmp3 AWE32_20SEC.wav AWE32_20SEC.mp3 -X2
C:\awe>madplay -d -v "AWE32_20SEC.mp3"
MPEG Audio Decoder 0.15.2 (beta) - Copyright (C) 2000-2004 Robert Leslie et al.
00:00:02 Layer III, VBR (avg 145 kbps), 44100 Hz, joint stereo (MS), no CRC
error: frame 98: bad audio data length
00:00:08 Layer III, VBR (avg 157 kbps), 44100 Hz, joint stereo (LR), no CRC
error: frame 325: bad audio data length
00:00:08 Layer III, VBR (avg 157 kbps), 44100 Hz, joint stereo (MS), no CRC
error: frame 333: bad audio data length
00:00:08 Layer III, VBR (avg 157 kbps), 44100 Hz, joint stereo (MS), no CRC
error: frame 341: bad audio data length
00:00:11 Layer III, VBR (avg 157 kbps), 44100 Hz, joint stereo (MS), no CRC
error: frame 460: bad audio data length
00:00:12 Layer III, VBR (avg 156 kbps), 44100 Hz, joint stereo (MS), no CRC
error: frame 468: bad audio data length
error: frame 469: bad audio data length
00:00:12 Layer III, VBR (avg 155 kbps), 44100 Hz, joint stereo (MS), no CRC
error: frame 488: bad audio data length
00:00:12 Layer III, VBR (avg 154 kbps), 44100 Hz, joint stereo (MS), no CRC
error: frame 496: bad audio data length
00:00:14 Layer III, VBR (avg 148 kbps), 44100 Hz, joint stereo (MS), no CRC
527 frames decoded (0:00:13.7), +0.2 dB peak amplitude, 2 clipped samples
C:\awe>lame --decode AWE32_20SEC.mp3
input: AWE32_20SEC.mp3 (44.1 kHz, 2 channels, MPEG-1 Layer III)
output: AWE32_20SEC.mp3.wav (16 bit, Microsoft WAVE)
skipping initial 529 samples (encoder+decoder delay)
Frame# 97/537 40 kbps MS mpg123: Can't rewind stream by 33 bits!
Frame# 323/537 96 kbps MS mpg123: Can't rewind stream by 33 bits!
Frame# 330/537 80 kbps MS mpg123: Can't rewind stream by 63 bits!
Frame# 337/537 80 kbps MS mpg123: Can't rewind stream by 52 bits!
Frame# 455/537 64 kbps MS mpg123: Can't rewind stream by 54 bits!
Frame# 462/537 80 kbps MS mpg123: Can't rewind stream by 108 bits!
Frame# 462/537 112 kbps MS mpg123: Can't rewind stream by 54 bits!
Frame# 480/537 80 kbps MS mpg123: Can't rewind stream by 33 bits!
Frame# 487/537 64 kbps MS mpg123: Can't rewind stream by 54 bits!
Frame# 527/537 32 kbps MS
Just an FYI..
Will anyone work on this encoder and tweak/tune it? AFAIK, so far all that's been done is tidying up the code, right?
I've done some ABXing at -V65 and I have failed miserably so far. I've tried a few metal tunes but can't distinguish them from the original. (I hope to improve my ability though!) Anyway, since I can't ABX music at -V65 I have actually started to encode my music for my portable with Helix! I just can't ignore the phenomenal encoding speed! So I'm kinda hoping the encoder will improve quality wise!
edit: added the second paragraph
I've now posted the version with the modifed user interface at Rarewares 'mp3' page. I've done a little more tidying up than just the above.
[a href="index.php?act=findpost&pid=316239"][{POST_SNAPBACK}][/a]
This little patch clears up a problem with compiling on u*ix boxen and shows the progress every 100 frames.
--- tomp3.cpp.old Thu Jul 28 15:05:19 2005
+++ tomp3.cpp Thu Jul 28 15:06:37 2005
@@ -486,7 +486,9 @@
if(strcmp(filename,"-")==0)
{
handle=stdin;
- setmode( fileno( handle ), O_BINARY );
+#ifdef _WIN32_
+ setmode( fileno( handle ), O_BINARY );
+#endif
}
else
handle = fopen ( filename, "rb" );
@@ -550,7 +552,9 @@
if(strcmp(fileout,"-")==0)
{
handout=stdout;
- setmode( fileno( handout ), O_BINARY );
+#ifdef _WIN32_
+ setmode( fileno( handout ), O_BINARY );
+#endif
}
else
handout = fopen ( fileout, "w+b" );
@@ -702,7 +706,8 @@
/*
* progress indicator
*/
- if ( ( u & 127 ) == display_flag )
+ if ( display_flag )
+ if (((Encode.L3_audio_encode_get_frames() + 1) % 100) == 0)
{
fprintf (stderr, "\r %6d/%8d (%3d%%)| %8d | %6.2fkb
ps | %6.2fkbps",
Encode.L3_audio_encode_get_frames() + 1, in_byte
s, (int)(in_bytes*100./infilesize), out_bytes,
@inhouseuk: I've applied your patch, recompiled and uploaded again.
It will be great if some moderators clean this thread and open a new one with the development discussion. It's interesting for sure but not for simple users.
Yes, and it would be nice to see this encoder announced in the front page of HA.org as validated new
Yeah. That'll be great if this encoder can be improved.
Will anyone work on this encoder and tweak/tune it? AFAIK, so far all that's been done is tidying up the code, right?
Actually, there's some bug-fixes. Not just tidying up of the code.
The encoder can't encode wav's containing odd characters such as: é, è, ü, ö, ä, å" etc. The encoder just skips those files, so all of a sudden you have a couple of tracks missing after an encode!! Can that be fixed? (shouldn't be too hard..?)
If you use Foobar as a frontend, files with the non-English characters (at least German umlauts and French accent aigu and accent grave, I haven't tried any others) will be encoded.
Ok, so it's rather a frontend problem and not a Helix problem then? How do I set it up with Foobar2000?
For example, you can use
- %d -V75 -X -U2
for VBR 75 encoding with foobar2000, where "-" represent stdin.
For example, you can use - %d -V75 -X -U2
OK, new guy here
How 'bout EAC or CDEx ? Code above doesn't seem to work.
CDEx calls the command promt window with hmp3.exe but it just hangs there.
Using just -V75 -X -U2 does not create mp3 file whatsoever (only wav).
EDIT: EAC seems to work with %s %d -V75 -X -U2, tough returns pointless error code.
No luck with CDEx so far.
EDIT 2: CDEx specific problem? http://cdexos.sourceforge.net/boards/index...?showtopic=2438 (http://cdexos.sourceforge.net/boards/index.php?showtopic=2438)
lame.exe won't for me also.
I use this command line successfully with CDex:
%1 %2 -V100 -X2 -U2
Be sure to untick "On the fly encoding" or CDex will crash completely.
As for EAC, I too get the error code. Solution for me was to untick "Check for external programs return code" under compression options.
As I did frequency analysis on the mp3 files, compared to the original ones,
I noticed a silence preceding the result audio of approx 0.076 seconds.
It's very annoying doing analysis, cause you have to cut it out each time.
Does anybody know where does this piece of silence comes from ?
Can it be fixed in the code ?
Encoder delay and padding. For Layer 3, that would be:
Encoder delay: Usually 576 samples for LAME, but I dunno about this... (chop from beginning)
Decoder delay: 529 samples for layer 3, chop from beginning.
Encoder padding: N samples at both beginning and end, includes decoder delay.
So, assuming encoder delay is 576, chop 576+529 samples from start of track, and chop the end to match the original input. Or, you can use foobar2000's VBR header fix tool and set the encoder delay and original input length there.
I have been making some ABX tests, particularly, I am very interested in this encoder and of being able to obtain from him the greater possible quality.
I have tested some samples of the "upload section", but I found two samples that caught my attention, in where this encoder has problems:
distort_guitar.wav (http://www.hydrogenaudio.org/forums/index.php?act=Attach&type=post&id=1406)
Originalsmall.flac (http://rarewares.soniccompression.com/quantumknot/Originalsmall.flac)
RESULTS:
distort_guitar.wav:
Easy ABX (8/8) in: -V100 -X2 -HF2 -F19000
this sample is also ABXable (for me) in: -V130 -X2 -HF2 -F19000
the artifact is a phasing effect, more easy to listen in -V100.
Lame3.97a11 (-V2 setting): transparent for me, I can't ABX.
----------------------------
Originalsmall.flac
ABXable for me in: -V150 -X2 -HF2 -F19000
the artifact is a very short shhhhhh sound in the beginning of the file.
Lame3.97a11 (-V2 setting): transparent, I can't ABX.
----------------------------
My impression is that this encoder is having some problem with some strong signals as heavy synths and heavy guitars, but probably this can be fixed doing some "tweak" in the code, maybe, doing some change in the block switching algorithm, but, it's only a supposition.
For example, in Originalsmall.flac Lame3.97a11 has 44% in short blocks; and Helix has only 18.7% in short blocks.
In distort_guitar.wav Lame3.97a11 has 1.3% short blocks, and Helix has 0% short blocks!! in this sample Helix doesn't have any short blocks, only long blocks.
Probably this problem with these two critic samples would be solved doing the block switching algorithm more sensitive.
Can anybody make some tweaks for this encoder to make it better?
I don't think CML or I have the ability to further tweak this encoder . I'm sorry for that. But I really hope this encoder can be improved quality wise.
We also need to know Karl's attitude if somebody can intensively tweak this encoder .
I second that. The phenomenal speed is just too good to pass up. Perhaps someone could also include the possibility to accept ID3 tags.
Probably this problem with these two critic samples would be solved doing the block switching algorithm more sensitive.
[a href="index.php?act=findpost&pid=317293"][{POST_SNAPBACK}][/a]
It looks like the threshold is hard coded in mp3enc.cpp
t = attack_detectSBT_igr ( sample[0][igrx_ahead], attack_buf[0],
side_info.gr[igr_prev][0].short_flag_next );
short_flag = 0;
if ( t > 700 )
{
short_flag = 1;
}
It might be worth playing around with the value to see if it is possible to increase the number of short blocks.
Do too many short-blocks suffer the quality, or has other side-effect simutaneously?
Anyway, it's worth tweaking with the threshold. We'll see if the problem reported by level can be solved via this tuning.
Since CML reinstalled the OS of his computer, can someone, maby John33, make a test build with switch can set this value mannually?
It might be worth playing around with the value to see if it is possible to increase the number of short blocks.
In Lame the short block threshold is defined according to the target bitrate /vbr level. (you will probably want to encoder to be more sensitive to short blocks at higher bitrates, and using less short blocks at lower bitrates).
Beware of not using too many short blocks, as they hurt quality due to their low resolution in the frequency domain.
It might be worth playing around with the value to see if it is possible to increase the number of short blocks.
In Lame the short block threshold is defined according to the target bitrate /vbr level. (you will probably want to encoder to be more sensitive to short blocks at higher bitrates, and using less short blocks at lower bitrates).
Beware of not using too many short blocks, as they hurt quality due to their low resolution in the frequency domain.
[a href="index.php?act=findpost&pid=317363"][{POST_SNAPBACK}][/a]
So something like:
threshold = value - (multiplier * target_bitrate)
where value and multiplier can be set on the command line would probably better for testing purposes then?
looking at mp3enc.cpp a bit closer, it looks like the threshold is checked/used in more than one place.
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.
What's RPSL/RCSL license, briefly?[a href="index.php?act=findpost&pid=313226"][{POST_SNAPBACK}][/a]
I took a round of interpretation at the RPSL, and seems to be a nice license. But it also features one of the most thick legalese I ever found.
From my somewhat limited comprehension of what I read, I can comment that:
- It's a virotic license, like the GPL. What means that if you use any portion of their code in your program, you must open your whole program under the RPSL. Other modules that might be used by your program can be licensed under other terms, as long as they are compatible (and all licenses deemed compatible with the RPSL by RN are open source ones). See section 4.
- RPSL is compatible to the GPL, but not the other way around.
- There is lots of care regarding patent mess. They disclaim responsability over patents covering the code they distribute, and add a termination clause where you can't sue them over patents. Which bring me to my next comment...
- There is a termination clause. This is obviously not a good thing. If you look at the FSF licenses, BSD, or most other OSS licenses, you'll see there are no ways to terminate them.
Lack of a termination clause is important, because otherwise, you could be at the copyright holder's whim. You step out of the line, he terminates the license and you can't use that code anymore. The clause 11.1a worries me, particularly, because it brings the whole license into play for termination cause. And, as most licenses, RPSL is highly interpretative.
The rest is pretty much disclaimers, limitation of liability, no warranties, don't use our trademarks and the like.
We also need to know Karl's attitude if somebody can intensively tweak this encoder [a href="index.php?act=findpost&pid=317299"][{POST_SNAPBACK}][/a]
According to the license, you can go nuts and improve the code as much as you want, as long as you release all your improvements under the same license. Just be aware of that suspicious termination clause...
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.
[a href="index.php?act=findpost&pid=317501"][{POST_SNAPBACK}][/a]
in stereo mode (be it joint or simple) lame switches to short blocks on both channels when on one channel or both channels short blocks are triggered. in dual mono channel mode (-md, not recommended for stereo encoding, but for bi-lingual encodings) lame switches to short blocks only on those channels which triggered it.
What's RPSL/RCSL license, briefly?
In my understanding it is a license that includes:
*If you use some code covered by RPSL/RCSL license in a product, then your product must comply with the same license (thus can not be used in closed source applications, unlike LGPL)
*If you implement something in covered code, you give Real a royalty free license applying to both copyright and patent right to use it, but also to reproduce it in any other product, that do not specially needs to be covered by such license (ie if you implement in their code something covered by one of your patents then now have a royalty free license regarding this patent, including in their potential other products that may be closed source)
*The license can be terminated by Real
So in another language: "ReaL oWnz aLL YoUr WorK"
So overall this license is higly favorable to Real, and could cause concern to potential contributors.
However, it is still very interesting to see this source code, considering that it is now open knowledge.
As I know, if different block types used, some decoders may have trouble with such situation, even it's part of mp3 standard.
It is known to cause audible glitches on some Sony and Clarion car players.
According to the license, you can go nuts and improve the code as much as you want, as long as you release all your improvements under the same license. Just be aware of that suspicious termination clause...
Project Mayo again ?
detect.c, line 91
sum = 7.0e4f;
does this value have some relationship with the default threshold for block-switching, 700?
CML rev12 (Only for test) binary uploaded as usual, at the last post.
http://www.hydrogenaudio.org/forums/index....t=25&p=317595&# (http://www.hydrogenaudio.org/forums/index.php?showtopic=35540&st=25&p=317595&#)
* Add a switch -SBT that can set the short_block_threshold (default is 700). This value can range to negative values.
** Short block detection logic changed a little.
Any further testing is welcome. For the problem sample level offered http://www.hydrogenaudio.org/forums/index....c=35531&st=100# (http://www.hydrogenaudio.org/forums/index.php?showtopic=35531&st=100#) , can someone (level) find a -SBT value to let the distortion gone?
With SBT set to default, we can see if the block-switch logic change make any sence. This kind of result is also appriciated.
CML rev12 (Only for test) binary uploaded as usual, at the last post.
http://www.hydrogenaudio.org/forums/index....t=25&p=317595&# (http://www.hydrogenaudio.org/forums/index.php?showtopic=35540&st=25&p=317595&#)
* Add a switch -SBT that can set the short_block_threshold (default is 700). This value can range to negative values.
** Short block detection logic changed a little.
[a href="index.php?act=findpost&pid=317596"][{POST_SNAPBACK}][/a]
Can you make the amended source available somewhere as well.
Thanks
Gabriel
Is there any way to handle transient better by improve transient detector in the detect.c?
I think lame handle the transient in a more sophisticated way. Would you please enlighten us where's the correspond part in lame project we can find?
Can you make the amended source available somewhere as well.
Thanks
The source code package have been uploaded. Will you please check the modification, and see if it make any sense? Because CML and I are not familiar with mp3 specification and audio compression, so we must be very careful and try not to make things worse.
Any comment or testing result will be helpful.
Is there any way to handle transient better by improve transient detector in the detect.c?
I think lame handle the transient in a more sophisticated way. Would you please enlighten us where's the correspond part in lame project we can find?
There are several ways to make block size decision.
Gpsycho is switching to short blocks on PE surge, as suggested by the ISO demonstration model II, but with an improved PE computation. As PE is purely conceptual, this can be quite tricky.
NSpsytune using an high pass on the short blocks, and is detecting surges between the high passed short blocks.
From my short look at the Helix mp3 encoder, it seems to me that it is detecting short blocks using the output from the filterbank (this is also used in Lame4 and Uzura3). It is clearly the faster method, as this is the earliest place where such a detection can be made.
Regarding short blocks, as Xing had to deal without short blocks during a long time, it is possible that the encoder could have a quite good pre-echo prevention scheme for long blocks to overcome this, and so perhaps missed short blocks could be less critical with this encoder than with other ones.
If you want to tune the short block detection, it might be a good idea to use mp3x to check the output of different encoders.
As promised in another thread, I've performed a listening test at ~140 kbs, including Lame 3.96.1, Lame 3.97a11 --vbr-new and Helix rev11.
The results are presented in the Lame 3.97a11 testing thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=35905&view=findpost&p=317798).
For example, you can use
- %d -V75 -X -U2
for VBR 75 encoding with foobar2000, where "-" represent stdin.
[a href="index.php?act=findpost&pid=316572"][{POST_SNAPBACK}][/a]
Funny, I'm getting an error in fb2k when I use that encoding string:
ERROR (foo_clienc) : Writing to encoder failed
ERROR (foo_clienc) : Encoding failed
ERROR (foo_diskwriter) : Conversion failed.
parameters verbatum are: - %d -V75 -X -U2
any ideas?
For example, you can use
- %d -V75 -X -U2
for VBR 75 encoding with foobar2000, where "-" represent stdin.
[a href="index.php?act=findpost&pid=316572"][{POST_SNAPBACK}][/a]
Funny, I'm getting an error in fb2k when I use that encoding string:
ERROR (foo_clienc) : Writing to encoder failed
ERROR (foo_clienc) : Encoding failed
ERROR (foo_diskwriter) : Conversion failed.
parameters verbatum are: - %d -V75 -X -U2
any ideas?
[a href="index.php?act=findpost&pid=317859"][{POST_SNAPBACK}][/a]
Yes, I can give you two options:
1) If you haven't done it yet: you should set "Highest BPS mode supported" to 16 bit instead of 24 bit.
2) If you have a non-Intel PC (AMD), then you should remove the -U2 switch. I have an AMD Athlon and the encoding hangs when I include the -U2 switch.
Considering that the Real mp3 encoder is a speed champion, I am wondering how would it compete with Gogo, regarding quality.
I think that it might possibly provide better quality than Gogo.
I have downloaded CML's latest source code, created a diff against the code checked in on Helix, and sent it out for code review on the proper Helix mailing list: datatype-dev@helixcommunity.org. Depending on the speed of the response there, the changes should soon be checked in.
I modified the project file such that it can be checked in to the same folder as the source code. In addition I had to include some (double) typecasts to avoid compiler errors for ambiguous usage of pow, log, and log10.
EDIT: changed typecast to (double) from (float)
I've been real pleased with the performance of this encoder - the speed is really unbeatable, and the quality is fine for my purposes. A few comments:
1. I'm using an Athlon for encoding, and I have no troubles with the U2 flag.
2. I have a script that pipes a shntool output into an mp3 encoder and looks for the return code of the mp3 encoder for success...and when I use mp3enc, it always returns a failure code. Can this be changed?
3. I don't know what the difference between the icl9 and vc7 versions is - can someone enlighten me?
Thanks!
3. I don't know what the difference between the icl9 and vc7 versions is - can someone enlighten me?[a href="index.php?act=findpost&pid=318108"][{POST_SNAPBACK}][/a]
Compiler used.
ICL9: Intel C Compiler
VC7: Microsoft C Compiler
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 (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 use this command line successfully with CDex:
%1 %2 -V100 -X2 -U2
Be sure to untick "On the fly encoding" or CDex will crash completely.
As for EAC, I too get the error code. Solution for me was to untick "Check for external programs return code" under compression options.
[a href="index.php?act=findpost&pid=316753"][{POST_SNAPBACK}][/a]
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# (http://www.hydrogenaudio.org/forums/index.php?showtopic=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.
Hmmm, can't see anything obvious. I'll look closer later.
[a href="index.php?act=findpost&pid=330012"][{POST_SNAPBACK}][/a]
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.
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!!
[a href="index.php?act=findpost&pid=330171"][{POST_SNAPBACK}][/a]
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.
CML rev12 (Only for test) binary uploaded as usual, at the last post.
http://www.hydrogenaudio.org/forums/index....t=25&p=317595&# (http://www.hydrogenaudio.org/forums/index.php?showtopic=35540&st=25&p=317595&#)
* Add a switch -SBT that can set the short_block_threshold (default is 700). This value can range to negative values.
** Short block detection logic changed a little.
Any further testing is welcome. For the problem sample level offered http://www.hydrogenaudio.org/forums/index....c=35531&st=100# (http://www.hydrogenaudio.org/forums/index.php?showtopic=35531&st=100#) , can someone (level) find a -SBT value to let the distortion gone?
With SBT set to default, we can see if the block-switch logic change make any sence. This kind of result is also appriciated.
[a href="index.php?act=findpost&pid=317596"][{POST_SNAPBACK}][/a]
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 -TX0A 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 kbpsFor 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.
MY COMMAND LINE: -V120 -X2 -HF2 -SBT450 -TX0
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?
Anyone?
MY COMMAND LINE: -V120 -X2 -HF2 -SBT450 -TX0
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?
Anyone?
[a href="index.php?act=findpost&pid=338769"][{POST_SNAPBACK}][/a]
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)
Could you tell us what the "-TX" parameter is? The documentation (such as it is) left me in the dark. Thank you.
[a href="index.php?act=findpost&pid=338790"][{POST_SNAPBACK}][/a]
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 (http://rapidshare.de/files/8374959/helix.rar.html)
Please help me, this bug is making me anxious about my music.
Thx
Rüdiger
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 (http://rapidshare.de/files/8374959/helix.rar.html)
Please help me, this bug is making me anxious about my music.
Thx
Rüdiger
[a href="index.php?act=findpost&pid=346521"][{POST_SNAPBACK}][/a]
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.
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.
[a href="index.php?act=findpost&pid=348991"][{POST_SNAPBACK}][/a]
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 (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
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)
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...
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.[a href="index.php?act=findpost&pid=349603"][{POST_SNAPBACK}][/a]
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).
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.[a href="index.php?act=findpost&pid=349603"][{POST_SNAPBACK}][/a]
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).
[a href="index.php?act=findpost&pid=349925"][{POST_SNAPBACK}][/a]
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
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.[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=349603")
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).
[a href="index.php?act=findpost&pid=349925"][{POST_SNAPBACK}][/a]
I reported the first recognized error to J.River and they fixed it,[a href="index.php?act=findpost&pid=350019"][{POST_SNAPBACK}][/a]
Here's what we found at J. River:
[a href="http://yabb.jriver.com/interact/index.php?topic=30468.msg209701#msg209701]http://yabb.jriver.com/interact/index.php?...09701#msg209701[/url]
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.
[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?!?
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.
[a href="index.php?act=findpost&pid=317501"][{POST_SNAPBACK}][/a]
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) (http://yabb.jriver.com/interact/index.php?topic=30718.0) « 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.
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:
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.
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;
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 (http://www.rarewares.org/mp3.html)
and a version with the potential fix (diff above) from helix community:
Helix Binary Downloads (https://helixcommunity.org/beula/download/)
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.
OK, already tested the new build on my problematic sample (Benassi Bros)
Seems to work now also using stereo mode 1 (JS)
THANKS, KARL, TO YOU AND YOUR COLLEAGUE!
I am glad to hear this. I have forwarded the information and your thanks to my colleague.
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.
[a href="index.php?act=findpost&pid=351590"][{POST_SNAPBACK}][/a]
Hmm, I must have missed the stdin input fix when I updated the Helix code a few months back, with what I thought were all the contributions from people on this thread. John33 applied the joint stereo patch to the rarewares source and built this separately. Therefore stdin works there. When I get back over the holidays I will patch the Helix source with the stdin fix. Thanks for noticing this.
I'd like to thank Karl as well. It's great that problems are getting fixed so promptly.
What's the difference between the -hf and -hf2 switches? Also, has anyone noticed them to give some sort of improvements in quality (by increasing low pass cutoff beyond 16 kHz on impulse-like parts)?
level posted earlier (post #170) that the encoder performed very well, in his opinion, with his command line. I wonder why no one has performed any ABX tests (and presented them)? I, for one, can't even ABX LAME @ -V 5 so it would be pretty useless.
There is one thing that has been bugging me for a while. Why do we need another open source mp3 Encoder if we already have Lame? I mean, Lame is great and is still being developed.
There is one thing that has been bugging me for a while. Why do we need another open source mp3 Encoder if we already have Lame? I mean, Lame is great and is still being developed.
[a href="index.php?act=findpost&pid=354391"][{POST_SNAPBACK}][/a]
because of the speed of this one, surely? The 'market' that Lame 3.xx addresses is the market for top-quality mp3 encoding. Sometimes quality is only one of several desiderata; sometimes you want to quickly transcode from archived lossless sources for portable use. That's the 'market' where alternative fast encoders like this are called for. It might also be useful for people with iPods with the Lame clipping problem (who for some reason want to stick with mp3 instead of using AAC instead).
There is one thing that has been bugging me for a while. Why do we need another open source mp3 Encoder if we already have Lame? I mean, Lame is great and is still being developed.
[a href="index.php?act=findpost&pid=354391"][{POST_SNAPBACK}][/a]
because of the speed of this one, surely? The 'market' that Lame 3.xx addresses is the market for top-quality mp3 encoding. Sometimes quality is only one of several desiderata; sometimes you want to quickly transcode from archived lossless sources for portable use. That's the 'market' where alternative fast encoders like this are called for. It might also be useful for people with iPods with the Lame clipping problem (who for some reason want to stick with mp3 instead of using AAC instead).
[a href="index.php?act=findpost&pid=354397"][{POST_SNAPBACK}][/a]
so is it much faster than gogo? How does the quality compare to gogo? Also, what is that Lame clipping issue on iPods you refer to?
There is one thing that has been bugging me for a while. Why do we need another open source mp3 Encoder if we already have Lame? I mean, Lame is great and is still being developed.
[a href="index.php?act=findpost&pid=354391"][{POST_SNAPBACK}][/a]
I am a big fan of Lame too; however, Which is the problem with to have other alternatives? I like to have other alternatives; mainly, with this encoder that is extremely fast with good quality, probably not as good as Lame; but very close. At least, I have been able to see this with my ABX tests (in post #170), and that nobody until the moment has taken the time (or the interest) in checking.
Lame is the excellent encoder that is today by the effort of the developers and the extensive listening tests. I am sure that this Real encoder (Xing?) with some effort and tweaks could be a excellent competitor.
That I know, HA is a open-site to discuss and to improve encoders; not only one. The opposite to this is a close-mind position.
level posted earlier (post #170) that the encoder performed very well, in his opinion, with his command line. I wonder why no one has performed any ABX tests (and presented them)?
[a href="index.php?act=findpost&pid=354243"][{POST_SNAPBACK}][/a]
me too.
Actually, I think there is a general lack of interest in this mp3 encoder and people tend to be more interested in testing lame. For instance, I wasn't expecting a reply to my post about the -HF switch
so is it much faster than gogo? How does the quality compare to gogo? Also, what is that Lame clipping issue on iPods you refer to?
[a href="index.php?act=findpost&pid=354405"][{POST_SNAPBACK}][/a]
As for quality compared with gogo, well, Real's mp3 encoder is basically an improved version of Xing (Xing used only long blocks while Real's added block switching to it), so I guess we could somehow refer:
(http://www.rjamorim.com/test/mp3-128/plot12z.png)
I'm not too familiar with the lame clipping issue but I have heard that lame mp3s encoded with --alt-preset tend to skip on the iPod while the helix mp3s at this bitrate range are fine.
so is it much faster than gogo? How does the quality compare to gogo? Also, what is that Lame clipping issue on iPods you refer to?
[a href="index.php?act=findpost&pid=354405"][{POST_SNAPBACK}][/a]
Regarding the first two questions, I can only go by the comparisons made or linked to earlier in this thread. And sure, gogo is a contender here too. But this encoder is also a relatively recent arrival, another reason why there's an active thread about it at this time (which is more or less what your question was about, I thought).
Regarding the third, I was intending to refer to the skipping/stuttering problem that's been reported sometimes for Lame playback on the 2G+ iPods, minis and so-forth - I have no idea why i typed 'clipping' instead. Probably the scotch talking. My bad.
Is it only me If i try to encode some music that starts loud and has no silence in the beginning an ugly loud "click" is added.
Edit: I found the answer myself. Some of my wav samples on the HD produce these clicks. These wavs are having longer wav headers for some reason. I don´t know with what application they were made but opening them in audacity and saving them again shortens this header and the clicks in the beginning while encoding dissapear.
Just tried -V120 -X2 -HF2 -SBT450 -TX0 -F18600 on trumpet, herding_calls and atem-lied (from problem sample and lame_attack thread).
Helix encoder yielded results which are perfect to me. The 'normal' music tracks I tried were fine as well.
I've been a very high bitrate CBR/ABR fan so far but about to convert to VBR of this kind.
Halb27: You keep talking about these same samples over and over. Do you realize that this encoder is underperforming on a lot of other samples?
Halb27: You keep talking about these same samples over and over. Do you realize that this encoder is underperforming on a lot of other samples?
[a href="index.php?act=findpost&pid=356474"][{POST_SNAPBACK}][/a]
Which samples? I would be very interested in some comparative data especially at low bit rates.
Halb27: You keep talking about these same samples over and over. Do you realize that this encoder is underperforming on a lot of other samples?
[a href="index.php?act=findpost&pid=356474"][{POST_SNAPBACK}][/a]
You are right, I'm concentrating on rather few problem samples apart from 'normal' tracks.
But what's wrong with it? If everybody shares his experience with those samples he knows best that's the way to go IMO.
I'm very interested in the other samples the encoder is underperfoming. Please share your experience.
At least Helix doesn´t add this sandpaper scratching noise to the other samples. Since 397 --vbr-new does this on a regular basis Helix at these high settings is often better than the actual V2 Hydrogenaudio recommendation
I encoded some music and have to say the HF performance is poor to even my aged ears. Like old fhg encoders it just lets pretty audible information dissapear.
Here is a very obvious sample and no, it is not only a spectral view problem.
Helix HF sample (http://www.hydrogenaudio.org/forums/index.php?showtopic=40653)
People have talked about speed of LAME encoding, yet nobody seems to have noted the speed improvement in LAME 4.0 alpha builds.
I encoded some music and have to say the HF performance is poor to even my aged ears. Like old fhg encoders it just lets pretty audible information dissapear.
Here is a very obvious sample and no, it is not only a spectral view problem.
Helix HF sample (http://www.hydrogenaudio.org/forums/index.php?showtopic=40653)
[a href="index.php?act=findpost&pid=357678"][{POST_SNAPBACK}][/a]
What a pity.
I have put a lot of hope into this encoder because with all the music I had encoded so far things were fine to me.
Personally I can't hear the problem, but as I know from many problem samples I can't really concentrate on samples which are very much opposed to my musical taste.
How do you rate HF performance of other encodings? Does it look like being a rather isolated problem or is it more a problem of general HF behavior?
People have talked about speed of LAME encoding, yet nobody seems to have noted the speed improvement in LAME 4.0 alpha builds.
[a href="index.php?act=findpost&pid=357682"][{POST_SNAPBACK}][/a]
From what i remember of when i tried it, it simply uses -q 5, as opposed to -q 2 ( -q 3 in lame 3.97), which is part of the reason of this speed increase.
Lame 4.0 is completely different from the 3.9x versions. This is the reason of the speed increase.
I encoded some music and have to say the HF performance is poor to even my aged ears. Like old fhg encoders it just lets pretty audible information dissapear.
Here is a very obvious sample and no, it is not only a spectral view problem.
Helix HF sample (http://www.hydrogenaudio.org/forums/index.php?showtopic=40653)
[a href="index.php?act=findpost&pid=357678"][{POST_SNAPBACK}][/a]
You know that the general performance of any encoder cannot be determined by only one difficult sample.
For example Helix [-V120 -X2 -HF2 -SBT450 -TX0] beats Lame3.97b2[-V2] in the infamous aps_killer_sample. You do ABX tests in this difficult sample and you will see that Helix to perform a lot better than Lame there.
And you know that I could not suggest that Helix is better than Lame by that, right?
I used Helix [-V120 -X2 -HF2 -SBT450 -TX0] to test your sample (without the -F19000 combination). In my post #170; I described that the -F19000 combination was redundant, because only -HF2 has a cutoff in 19500 Hz. In addition, I said that apparently -F19000 was adding something of phasing effect there; however I suspect that you probably don't read this. If you want to test high frequency behavior the result will be more reliable without the -F combination and with HF2 enabled, not HF that is buggy.
The results were the same than halb27: I don't hear nothing bad there; In fact, it was transparent for me. In addition, I did a spectral analysis with Cool Edit Pro and the high frequency component (>16 Khz) is alive there. With velvet sample I did a spectral view too, and the high frequency component (>16 Khz) is very strong there.
I did a lot of tests concerning HF behavior last night being worried a lot because of Wombat's result.
After all this abxing HF rich 'normal' music I keep up being happy with Helix. Of course this is pure subjective. However I think despite my age I'm not totally insensitive towards HF behavior according to my mp3 listening tests at lower bit rates where lowpassing is a must and where my abx successes have often ben founded on differences in HF. Not a real argument I know.
Anyway there is something specific with Wombat's sample as I have seen in spectrum analysis. HF is cut off way below 18.6 kHz (even without the explicit lowpassing). But I've seen it only with this sample . Spectrum analysis with other samples I've tried was in accordance with explicit lowpassing and did not cut off HF additionally.
I did a lot of tests concerning HF behavior last night being worried a lot because of Wombat's result.
After all this abxing HF rich 'normal' music I keep up being happy with Helix. Of course this is pure subjective. However I think despite my age I'm not totally insensitive towards HF behavior according to my mp3 listening tests at lower bit rates where lowpassing is a must and where my abx successes have often ben founded on differences in HF. Not a real argument I know.
Anyway there is something specific with Wombat's sample as I have seen in spectrum analysis. HF is cut off way below 18.6 kHz (even without the explicit lowpassing). But I've seen it only with this sample . Spectrum analysis with other samples I've tried was in accordance with explicit lowpassing and did not cut off HF additionally.
[a href="index.php?act=findpost&pid=357982"][{POST_SNAPBACK}][/a]
I have not tested much with Helix. I threw in some of my sample folders and listened. This sample was easy to catch to me so i reported it.
I have to admit that i tried some more diffcult HF samples and found nothing else.
Just for the record i did another ABX with my dm_s sample and reached 8/8 without a problem.
@level
I will try your suggestion and leave out the forced lowpass.
Other than that Helix is impressive immune against artifacts!
If somehow the "Accurate Lenght" info could be implemented it would be a very complete solution.
Be cautious when commenting about spectral analysis here. The HF behaviour of Helix seems very similar to that of Xing (though that shouldn't be surprising). That is, the > 16 kHz cutoff only occurs during sharp transients, not all the time like in iTunes AAC or Vorbis.
Be cautious when commenting about spectral analysis here. The HF behaviour of Helix seems very similar to that of Xing (though that shouldn't be surprising). That is, the > 16 kHz cutoff only occurs during sharp transients, not all the time like in iTunes AAC or Vorbis.
[a href="index.php?act=findpost&pid=358035"][{POST_SNAPBACK}][/a]
dm_s is of that kind. That´s why lame seems to be that better here.
Finally I succeed to hear the problem with dm_s (10/10). Before I was concentrating on the obvious bright sounding parts, but now I realize the problem from the very beginning of the sample where the sound is rather sonore on first 'glance' but does have HF parts.
Once heard I find the problem rather obvious too.
Not to do explicit lowpassing doesn't change things.
Now that we know thanks to QuantumKnot this behavior is triggered by transients I had a look again at trumpet, herding_calls and atem-lied. Spectrum analysis showed the same behavior for trumpet and atem-lied (atem-lied spectrum looks reals strange in the 16 kHz area).
But I could not reliably abx, neither trumpet nor atem-lied.
Well, HF behavior isn't excellent. But if this is the trade for preventing artefacts to a great extent (and it looks like that) I am content.
What impresses me most is VBR behavior. I use -V140 (tribute to my paranoia) and found with difficult samples average bit rate goes up to something like 280 kbps, while easy tracks are encoded with something like 170 kbps average bitrate.
Usually average bit rate is around 225 kbps.
I will use Helix for my forthcoming productive encodings, but will switch back to Lame as soon as the distortion or 'sandpaper' problem is solved.
I just tested the real bad pre-echo sample eig with HELIX (among other encoders).
Helix -V120 -X2 -SBT450 -TX0 -HF2 isn't transparent of course, but to me precision is better than with other mp3 encoders even when using higher bitrate settings (including 3.97b3 -V0, 3.90.3 api).
It has been mentioned that Helix at higher quality settings seems to be rather robust against artefacts. I just was impressed by Helix' performance on eig using level's setting with -V120 and -V150.
This motivated me to investigate the drawback of Helix, HF behavior, in more detail.
I did a lot of encodings from my musical archive, and usually everything was fine to me. But it was not always like that. With Fleedwood Mac's Rhiannon (from the album 'Gretest Hits') I could abx 9/10 missing HF in the 18...21 sec range. I looked at the spectogram and saw that there is something like a soft limit at 16 kHz - not very much is encoded beyond 16 kHz.
I played around a bit and found HF content increases with quality setting - compared to -V120 it's better with -V150 and even better with -B160 (cbr320). But it didn't totally help with the spot I found.
Playing around a lot I finally found that in this case explicitly omitting the range beyond 16 kHz is the best way to go. When I didn't use the -HF2 switch I couldn't reliably abx any more. Looks like -HF2 has an effect on the range below 16 kHz.
I was not fond of giving away everything beyond 16 kHz but I gave it a try. I tested a lot of samples and often thought I found something missing. But abxing showed me I was wrong. After so much work and becoming aware that I'm obviously too old or too deaf to hear anything beyond 16 kHz I was lucky I finally found a spot in Rickie Lee Jones' version of Under the Boardwalk where I got at least a 8/10. But I had a hard time with it.
After all this work I feel I really don't miss something within real live listening situations if I don't get something from sfb21.
Sure this will be different for young people or other people with good HF listening capabilities, but keeping in mind that with the last 128 kbps listening test
Lame -V5 with its 16 kHz lowpass was more or less transparent to many testers so may be being having a 16 kHz limit isn't an issue to other people too.
I also tried Wombat's dm_s sample one more time. I could easily abx the missing HF but looking closer at it I found this is true to me only at the very start. When I started the abx range just a fraction of a second away from the very start I couldn't abx the problem. This doesn't say that everything is fine, and looking at the spectogram it is obvious that not much is encoded beyond 16 kHz (and in this case using -V150 or -B160 doesn't improve things), but at least the pretty audible (to me) issue is limited to the very start where it is not uncommon that encoders behave in a suboptimal way.
Because of the extraordinary robustness against pre-echo and other problems I will use Helix -V120 -X2 -SBT450 -TX0 (apart from wavPack lossy for the best of my music) until the Lame 3.98 branch has come to full maturity.
Where can I find a helix frontend?
Thanks
I use foobar as a universal encoding frontend.
You can configure any CLI encoder to work with foobar.
News about Helix' non-ideal HF behavior resp. HF setting:
When new dBpoweramp came out I found myself very happy with it, bought it, and re-ripped all of the CDs that are of great value to me (also because I don't have all of these valuable tracks as ape-Files).
At the same time I realized I can play AAC on my rockbox armed H140 and gave it a try.
What I found with one of my latest CDs (Sandrine Kiberlain: Manquait plus qu'ça) which is an absolute favorite of mine is that the AAC encodings have a more 'vivid' sound than my Helix -B128 -X2 -SBT450 -TX0 encodings I know very well. I was able to abx the difference (this however was hard while the mere-listening difference seemed obvious to me). I gave -HF2 another try and things became alright (at least with abxing - I still have the impression it's not exactly as 'vivid' as the AAC encodings, but I guess that's placebo).
So I will use -HF2 again.
The beforementioned CD by Sabrine Kiberlain showed up more problems.
Sibilants aren't reproduced very well, and I found HF spots with percussion in the background where differences to the original are audible, and fiddling around with the settings doesn't really help (and is a bad option anyway).
I should mention that I'm talking about subtle differences but for very high bitrate I don't find it very acceptable. The lacking 'vividness' of my last post did I find by mere listening because I know this CD very well. Same is true for the sibilants.
So Helix is not the good encoder I hoped it is.
In the high bit range area I prefer again good old Lame 3.90 (hopefully soon: 3.98). Things might look different for people who often listen to music that is prone to pre-echo effects, as it looks like Helix really shines in this field.
Helix does have it's merits because it's still true to me that it is robust against artefacts, and that it's VBR method is very well behaved. But Helix works no miracle, it's just a respectable competitor, and maybe the sweet spot using it is something like -V55 ... -V120 depending on personal considerations.
Added:
I should remark that the sibilants on this CD may be problematic to other encoders too. I am about to try Nero CLI AAC for my Rockbox based H140 and I found -q 0.6 may have a very slight problem too. Exactly speaking I was not able to reliably ABX the problem so formally speaking there is no problem. But I can't totally ignore it as within the first 5 trials I could identify the suspected encoding in a rather reliable way. I abxed several sessions and usually it was like this.
I just wanted to say that I really like this codec for it's speed! I've taken to using this in foobar to transcode lossless to MP3 for my flash portable (iAudio G3), and on average it takes only 1:00 to 1:15 to transcode a single album, vs. 3:30 to 4:00 with LAME vbr-new (w/ dual-core processor).
I realize that quality may not be up to LAME per listening tests (and general public perception) but it's quite adequate enough for my temporary transcodes (non-golden ears, listening on cheaper headphones).
Has there been any further development on this encoder? I assume not; I'm using the version up at rarewares last updated December 2005.
I currently use -V75 (yields bitrates roughly equivalent to LAME -V4) -X2 -U2 in my command line. Would someone be able to explain in layman's terms what the -TX switches do (and if one is already default), and/or what tweaking the SBT accomplishes? For reference I've put the hmp3.exe -help below - I find it to be a bit cryptic.
file-file MPEG Layer III audio encode v5.1 2005.08.09
Copyright 1995-2005 RealNetworks, Inc.
Usage: mp3enc <input> <output> [options]
<input> and/or <output> can be "-", which means stdin/stdout.
Example:
mp3enc input.wav output.mp3
Options:
-Nnsbstereo -Sfilter_select -Aalgor_select
-C -X -O
-D -Qquick -Ffreq_limit -Ucpu_select -TXtest1
-SBTshort_block_threshold -EC
-h (detailed help)
B[bitrate]Per channel bitrate in kbits per second.
Encoder will choose if -1. (default)
M[mode] Select encoding mode: mode-0 stereo=0 mode-1 stereo=1 dual=2 mono=3.
V[vbr_scale]
Selects vbr encoding and vbr scale. Valid values are 0-150.
N[nsbstereo]
Applies to mode-1 stereo mode only. Number of subbands to
encode in independent stereo. Valid values are 4, 8, 12, and 16.
The encoder limits choices to valid values. The encoder
will make a default selection if nsbstereo = -1.
Valid values for Layer III are 3-32.
S[filter_select]
Selects input filtering: no filter = 0, DC blocking
filter = 1.
if filter = -1 the encoder will choose (default)
A[algor_select] 0 = track input, 1=MPEG-1, 2=MPEG-2, xxxxx=sample_rate
C c0 clear copyright bit, c1 set copyright bit
O o0=copy, o1=original
X MPEG compatable Xing header, -X2 with/TOC
U u0=generic, u2=Pentium III(SSE)
Q disable_taper, q0 = base, q1 = fast, q-1 = encoder chooses
D Don't display progress
F Limits encoded subbands to specified frequency, f24000
HF high frequency encoding. Allows coding above 16000Hz.
hf1=(mode-1 granules), hf2=(all granules), -B96 or -V80 need
TX tx6, test reserved 6 or 8 seems best (startup_adjustNT1B)
** v5.0 TEST 1 as of 8/15/00
** v5.0 TEST 2 8/18/00
** v5.0 TEST 3 default tx6 (prev = tx8)
** v5.0 TEST 4 mods to short fnc_sf, ms corr. hf enable > 80
** v5.0 TEST 5 fix odd npart, ix clear
** v5.0 TEST 6 add reformatted frames
** v5.0 TEST 7 drop V4 amod
** v5.1 2005.08.09 (see CVS log for details)
SBT[short_block_threshold]
short_block_threshold default = 700
EC Display Encoder Setting
Yes, speed is great, but quality also in many respects, and your choice of -V75 is in Helix' sweet spot range IMO. A very respectable competitor to Lame -V4.
The encoding options are really cryptic. I also tried to learn about the TX option and didn't find anything. According to my understanding of the help contents the default is TX6.
A while ago I did some testing with -V55 and to me the result was slightly better when not changing the defaults than using level's setting (-SBT450 -TX0) which is the only setting with specific experience available.
With -v75 I am experiencing severe ringing with nearly all music that has flanged electric guitars. Its damn quick encoder, but how do I make this ringing go and keep filesize sensible ?
@halb: thanx for the insight
@shadowking: That's interesting. I listen primarily to electronica/hip-hop and so far I haven't encountered any artefacts, though granted these are non-golden ears. Maybe you could post a short sample clip of the source so we can try some different switches?
Any updates on this?
Any updates on this?
I've seen Helix mp3enc v5.1 Open Source encoder patched 2005-12-20 on rarewares
I don't know if this is the latest CVS compile...
Since then i've seen... from http://www.dbpoweramp.com/codec-central-realaudio.htm (http://www.dbpoweramp.com/codec-central-realaudio.htm)
For dBpoweramp R12 or newer...
Real Audio Helix Encoder Release 5
Encodes to Real Audio (including Lossless), also included mp3 Helix encoder: a blisteringly fast encoder, 100x encoding speed (2GHz Dual Core), 4x faster than Lame.
But this seems to be the same as the one on Rarewares...
file-file MPEG Layer III audio encode v5.1
2005.08.09Copyright 1995-2005 RealNetworks, Inc.
Can someone verify this is the latest CVS?
The mp3 encoder *might* be updated in the new realplayer plus beta
I wonder what is the recommended command line for Helix MP3 encoder for files between ~ 170 - 185 kbps (Lame's -V 3 and -V 2)? Please can you suggest me one? I've found somewhere this command line:
For music:
-X2 -U2 -V120 - %d
For voice:
-X2 -U2 -M3 -V40 - %d
Regarding the previous post, it seems that there's also a newer version than the one on rarewares... On dBpoweramp codec central (http://www.dbpoweramp.com/codec-central-realaudio.htm) there is a
Real Audio Helix Encoder Release 6.
So how does Helix now compare to LAME?
So how does Helix now compare to LAME?
According to the previous posts - it is said that Helix is a bit worse in low bitrate settings and on par with the higher bitrates and is much faster encoder (5x to 10x realtime compared to Lame).
Regarding the previous post, it seems that there's also a newer version than the one on rarewares... On dBpoweramp codec central (http://www.dbpoweramp.com/codec-central-realaudio.htm) there is a Real Audio Helix Encoder Release 6.
This is
RealAudio encoder pack that also contains helix.
So how does Helix now compare to LAME?
http://listening-tests.hydrogenaudio.org/s...tian/mp3-128-1/ (http://listening-tests.hydrogenaudio.org/sebastian/mp3-128-1/)
According to the last public mp3 listening test at 128 kbps on average (2 years ago I guess) helix came out very well, judging from the usual average results it was on par with Lame, FhG and others.
Looking at the various test tracks in detail, each of the contenders had their weaknesses though overall results were great. Helix' weakness is with metal / hard rock music, but it was one of the best allrounders.
This is RealAudio encoder pack that also contains helix.
Yep, thanks for clarification. After decompressing the
dBpoweramp-encoder-helix.exe pack, I found out it is the same executable as the one found on rarewares.
Please can you suggest me a good command line for encoding around Lame's "
-V 3" ?
I'd use the command line from that listening test: -X2 -U2 -Vxx, with xx so that you get at the average bitrate you're targeting at. I guess xx ~ 80 will do.
So I suggest to use -X2 -U2 -V80, or similar.
I was wrong.
I just figured out with my standard test set of various pop music:
-X2 -U2 -V100 yields an average bitrate of 168 kbps.
For a comparison: Lame 3.98.4 -V3 yields an average bitrate of 166 kbps for this test set.
"Unholy thread resurrection, Batman!" I just read through it, also because of the last MP3 128 kbps listening test, and noticed that the embedded pictures of the speed comparisons by Nyaochi are gone, probably because he changed his website since then. So here is the latest version in English that I could find from late 2006:
http://nyaochi.sakura.ne.jp/encoder-benchmark/ (http://nyaochi.sakura.ne.jp/encoder-benchmark/)
If I understood it correctly, the -U2 switch is optimized for Pentium III with SSE, not for a Pentium 4 with SSE2 and newer versions, right? And has the mystery been solved what all the other switches used in this thread actually mean?
If I understood it correctly, the -U2 switch is optimized for Pentium III with SSE, not for a Pentium 4 with SSE2 and newer versions, right?
IMHO there's almost no point in using SSE2 in mp3 encoder.
And has the mystery been solved what all the other switches used in this thread actually mean?
I'd love to know the answer too.
Is it possible to compile Helix on Linux? Seems like the source package on Rarewares is Windows only.
Would it be possible to implement the gapeless support of LAME in Helix as well, or this functionality is too much tied to LAME?
Hi all,
I registered to this site solely to say a big thanx for all contributors in this thread! I used Helix for many years, but recently ugraded my audio gear (heaphones, cell phone etc.) and found that my mp3's are somewhat flat and lifeless compared to original CD. This was not so apparent before (hmm) but after doing some FLAC/WAV comparisions it became obvious. I did some tests, tried different parameters, with mostly poor results. I was prepared to abandon Helix in favor of different encoder, when by coincidence I've found this thread. Finally there are the right parameters to be used!!! I did a quick tests and I couldn't hear any difference with the original CDs. Resampled all of my CD collection, it took me some weekends, but even in a car I can hear much better output than before - rich sound, dynamic, sparkle! I use CDex with Helix as a command line encoder and the workflow is really fast - much faster these days with better CD ROM drives, and it takes Helix just several seconds to encode a song :-)
Again, thak you all, and for another internaut I'll repeat the magic parameters combination: "-U2 -HF2 -V150 -X2 -SBT450 -TX0"
Myrra
In the interest of those interested in doing the same, how did you resample all of your CD collection?
It's pretty easy and fast once you've got the right setup :-)
Long time ago, b.c. (before children) I used CDex and Helix in conjunction. CDex is able to automatically query CDDB database and use extenal encoder (which is Helix in my case) to process grabbed WAV files. Even there is an option to make a playlist and eject CD when the work is done.
So basically:
- I downloaded CDex (it can be found anywhere on the internet for free)
- I downloaded Helix (v5.1 is the latest one, dated, ugh, 2005)
Setup CDex
- setup directories and paths:
- create playlist: "Playlists\%1\%1 - %2", so it's directory "Playlists", subdir by artist and file is named by artist and album (checked "add files m3u playlist"). I know there are many "library" fnctions in players these days, but I prefer the old school way - best to play just a directory, not dealing with #$% mp3 tags...
- filename format: "%1\%2\%7 %2-%4", so it's saved in directory named by artist, then album, and file begins with track number, followed by album and track name
- ripping set to eject CD when ripping has been completed, and select all CD tracks by default
- use external encoder <your_path_here>\hmp3.exe with these parameters: %1 %2 -U2 -HF2 -V150 -X2 -SBT450 -TX0
- auto connect to freedb database. I didn't change anything other in the default settings (there are still some obscure CDs I had to enter manually, but database covers 99%). You might need to setup proxy connection if there is any on your nework.
This way, all you have to do is insert a CD, CDex automatically reads track names and selects them, you click on "Extract CD tracks to Compressed audio files" (I haven't figured how to automate THIS), ripping begins and at the end, there is a pop up sound when CD is ejected... insert another CD, and so on. I have some drawers pretty filled up with CDs, but generally don't use them - I prefer to utilize a heaphones and player/cell phone in my pocket. Judging from the playlist filecount, I ripped about 140 CDs, and took me some 2-3 weekends to do it.
Surely there are many other ways but I'm glad to use my old one - good workflows take a lot of effort :-o
Myrra
"Unholy thread resurrection, Batman!" I just read through it, also because of the last MP3 128 kbps listening test, and noticed that the embedded pictures of the speed comparisons by Nyaochi are gone, probably because he changed his website since then. So here is the latest version in English that I could find from late 2006:
http://nyaochi.sakura.ne.jp/encoder-benchmark/ (http://nyaochi.sakura.ne.jp/encoder-benchmark/)
If I understood it correctly, the -U2 switch is optimized for Pentium III with SSE, not for a Pentium 4 with SSE2 and newer versions, right? And has the mystery been solved what all the other switches used in this thread actually mean?
Links to those are here. nyaochi's encoder benchmarks (http://web.archive.org/web/20080316032228/http://nyaochi.sakura.ne.jp/encoder-benchmark/)
- use external encoder <your_path_here>\hmp3.exe with these parameters: %1 %2 -U2 -HF2 -V150 -X2 -SBT450 -TX0
Just to remind (myself), if using more than one work in filename/name, one has to add double quotes so that name is taken as a whole. Maybe I added this in my comment before and it dissapeared during parsing... anyway correct way is:
"%1" "%2" ... (double quotes around both parameter 1 and 2)
Myrra