new Open Source mp3 Encoder from Helix Community Options

[Julien]

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



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.



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.

[DarkAvenger]

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

CODE

BI
CountBits0 ( void *table, int ix[], int n )
{
   BI bi;

   bi.bits = bi.index = 0;
   return bi;
}

assembler (intel syntax)

CODE

_CountBits0 proc public

;; null case, ixmax = 0

   xor eax, eax
   xor edx, edx
   ret

_CountBits0 endp

disassembled (at&t syntax) + interleaved source

CODE

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

[pest]

no, gcc uses eax:edx as intel....

[DarkAvenger]

no, gcc uses eax:edx as intel....

Uhm, could you explain to me where you see that in above disassembled code?

[pest]

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

This post has been edited by pest: Jul 26 2005, 17:46

[DarkAvenger]

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

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

This post has been edited by DarkAvenger: Jul 26 2005, 19:07

[Synaptic Line No...]

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?

Jolly good sir!

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

Jolly good sir!

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.

[LoFiYo]

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

CODE

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

CODE

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

[DigitalDictator]

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

This post has been edited by DigitalDictator: Jul 28 2005, 08:53

[inhouseuk]

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.

This little patch clears up a problem with compiling on u*ix boxen and shows the progress every 100 frames.

CODE

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

[john33]

@inhouseuk: I've applied your patch, recompiled and uploaded again.

[kurtnoise]

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.

[guruboolez]

Yes, and it would be nice to see this encoder announced in the front page of HA.org as validated new

[Enig123]

Yeah. That'll be great if this encoder can be improved.

[Enig123]

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.

[DigitalDictator]

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

[LMS]

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.

[DigitalDictator]

Ok, so it's rather a frontend problem and not a Helix problem then? How do I set it up with Foobar2000?

[Enig123]

For example, you can use

CODE

- %d -V75 -X -U2

for VBR 75 encoding with foobar2000, where "-" represent stdin.

[suur13]

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

lame.exe won't for me also.

This post has been edited by suur13: Jul 29 2005, 21:30

[LMS]

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.

This post has been edited by LMS: Jul 30 2005, 03:35

[dirkvl]

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 ?

[kode54]

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.

[level]

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