new Open Source mp3 Encoder from Helix Community Options

[Enig123]

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

This post has been edited by Enig123: Jul 18 2005, 11:06

[spoon]

Enig123: Does this CLI encoder allow std input / output piping?

[Enig123]

Sorry. I'm afraid there's no pipe supporting for now.

Can someone give some link thant can indicate how to add such features?

[tycho]

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

CODE

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

CODE

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

CODE

/****** 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;
       }

This post has been edited by tycho: Jul 18 2005, 17:56

[karl_lillevold]

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

[Enig123]

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,

[Raffles]

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.

[Enig123]

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.

This post has been edited by Enig123: Jul 19 2005, 07:12

[Shade[ST]]

Rev 7 is out : command line piping support added.

http://www.hydrogenaudio.org/forums/index....ndpost&p=314509

[tycho]

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.

This post has been edited by tycho: Jul 19 2005, 10:40

[Enig123]

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.

This post has been edited by Enig123: Jul 19 2005, 10:38

[danchr]

CODE

       handle = fileno(stdin);

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

[spoon]

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.

For recording live stream over STDIO it is good to support 0 length files (ie unknown) and just keep writing until data stops.

[tycho]

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

This post has been edited by tycho: Jul 19 2005, 17:12

[Enig123]

rev8 binary uploaded.

Changelog

1) support stdout now
2) using "-" instead of "stdin" with previous rev7

You can do test with

CODE

mp3enc - - < 001.wav > 001.mp3

Use command like

CODE

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

Nyaochi's speed test has been updated (-U2 switch tested)

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

[guruboolez]

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)

CODE

• 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

CODE

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

CODE

FRIEDMAN version 1.24 (Jan 17, 2002) http://ff123.net/
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 >>>


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

This post has been edited by guruboolez: Jul 19 2005, 16:23

[rjamorim]

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

Great. Another proof that Xing isn't as bad as people used to depict it.

Thanks for the test, Guruboolez

[Enig123]

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.

[Enig123]

rev9 uploaded

many small tweaks
add -EC switch to display more information

[Squeller]

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

[john33]

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

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.

[Enig123]

There's a CML compiled binary in the rev9 bundle, which can be downloaded from http://www.hydrogenaudio.org/forums/index....showtopic=35540 .

[DarkAvenger]

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?

[level]

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,