new Open Source mp3 Encoder from Helix Community Options

[Synaptic Line No...]

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?

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/

[Enig123]

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.

This post has been edited by Enig123: Jul 21 2005, 08:14

[level]

CML's rev10
1). Length bug fixed, thank level

Yes, this works now; thanks to you .

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

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/

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

This post has been edited by DarkAvenger: Jul 21 2005, 08:40

[john33]

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?

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/

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.

[john33]

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:

CODE

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

[Enig123]

[/code] 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?

[danchr]

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

CODE

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" );

[Synaptic Line No...]

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?

This post has been edited by Synaptic Line Noise: Jul 25 2005, 19:10

[Enig123]

It should mean

CODE

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.

This post has been edited by Enig123: Jul 22 2005, 06:52

[john33]

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?

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.

This post has been edited by john33: Jul 22 2005, 09:48

[john33]

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:

CODE

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

[DarkAvenger]

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

[Enig123]

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

This post has been edited by Enig123: Jul 23 2005, 06:30

[john33]

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

[Enig123]

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.

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

[john33]

There's a place typing "200" as "2100" in the original code.

That's what I was referring to.

[dirkvl]

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.

[Madrigal]

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

[Enig123]

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.

Yeah. With -B >= 96 and -V >= 80, you can use -HF -F19000 or -HF2 -F19000 to achieve 19000 Hz lowpass.

[dirkvl]

Thanx guys. This setting just made my day.

Dirk.

[Synaptic Line No...]

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.

CODE

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.

CODE

   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

This post has been edited by Synaptic Line Noise: Jul 25 2005, 19:27

[john33]

How does:

CODE

 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?

[ak]

"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

[kindofblue]

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