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:

And similarly for the output file:


Add: You must also modify the CL processing:

Thanks for making these improvements and builds. Is there any chance you might consider contributing your improvements back to the Helix Community?

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/

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

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.

On most UNIX systems STDIN_FILENO will do the trick. I never developed on Windows, but it's probably defined there as well

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


Use command like

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.

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.5
group1 (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.19
VBR: 96 kbps Highest (default settings)

• LAME 3.97 alpha 11
ABR: --abr 101

• Real mp3enc V5.0 rev.6
VBR: -V20




calculated bitrate (short samples library)






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






<<< PLOTS >>>


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

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

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

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 .

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,

intel2gas, 1.3.3, A converter between the NASM and GAS asm format (Intel/AT&T)
http://freshmeat.net/projects/intel2gas/

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

Yes, this works now; thanks to you .

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

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: By changing the default, as above, all sample rates seem to encode quite happily, with upsampling working as I believe was intended.

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

I've been googling around for something you can use.

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

# 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

and the first br is current bitrate, second is averaged bitrate.

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

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


NOTE: This encoder only support mpeg-1&2, not 2.5, so it will never output mp3 with 11025 samplerate (22050 instead).

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.

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.

See post #51 in this thread. It would appear that the -F switch now does this.

Regards,
Madrigal

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.

This looks like "1281 bytes in" "5902848( 47%) bytes out "

Please add a LAME style progress text.



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

How does:grab you?

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