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.

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


assembler (intel syntax)


disassembled (at&t syntax) + interleaved source


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

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

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

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.

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



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

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

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

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

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

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.

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

It looks like the threshold is hard coded in mp3enc.cpp



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?

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.

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.

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.



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

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.

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.

It is known to cause audible glitches on some Sony and Clarion car players.

Project Mayo again ?

detect.c, line 91

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

* 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# , 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.

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?

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.

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.

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?

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!

Compiler used.

ICL9: Intel C Compiler
VC7: Microsoft C Compiler