new Open Source mp3 Encoder from Helix Community Options

[Enig123]

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 .

This post has been edited by Enig123: Aug 2 2005, 11:54

[kindofblue]

I second that. The phenomenal speed is just too good to pass up. Perhaps someone could also include the possibility to accept ID3 tags.

[inhouseuk]

Probably this problem with these two critic samples would be solved doing the block switching algorithm more sensitive.

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

CODE

   t = attack_detectSBT_igr ( sample[0][igrx_ahead], attack_buf[0],
                              side_info.gr[igr_prev][0].short_flag_next );
   short_flag = 0;
   if ( t > 700 )
   {
       short_flag = 1;
   }

It might be worth playing around with the value to see if it is possible to increase the number of short blocks.

[Enig123]

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?

This post has been edited by Enig123: Aug 2 2005, 13:56

[Gabriel]

It might be worth playing around with the value to see if it is possible to increase the number of short blocks.

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.

[inhouseuk]

It might be worth playing around with the value to see if it is possible to increase the number of short blocks.

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.

[Enig123]

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.

[rjamorim]

What's RPSL/RCSL license, briefly?

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.

We also need to know Karl's attitude if somebody can intensively tweak this encoder 

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

[robert]

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.

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.

[Gabriel]

What's RPSL/RCSL license, briefly?

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.

[Gabriel]

As I know, if different block types used, some decoders may have trouble with such situation, even it's part of mp3 standard.

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

[Gabriel]

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

Project Mayo again ?

[Enig123]

detect.c, line 91

CODE

sum = 7.0e4f;

does this value have some relationship with the default threshold for block-switching, 700?

[Enig123]

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.

This post has been edited by Enig123: Aug 3 2005, 14:19

[inhouseuk]

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.

Can you make the amended source available somewhere as well.

Thanks

[Enig123]

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?

This post has been edited by Enig123: Aug 4 2005, 04:00

[Enig123]

Can you make the amended source available somewhere as well.

Thanks

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.

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

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.

[bug80]

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.

This post has been edited by bug80: Aug 4 2005, 10:20

[jarsonic]

For example, you can use

CODE

- %d -V75 -X -U2

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

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?

This post has been edited by jarsonic: Aug 4 2005, 15:43

[bug80]

For example, you can use

CODE

- %d -V75 -X -U2

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

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.

[Gabriel]

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.

[karl_lillevold]

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)

This post has been edited by karl_lillevold: Aug 5 2005, 20:55

[Cerebus]

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!

[rjamorim]

3.  I don't know what the difference between the icl9 and vc7 versions is - can someone enlighten me?

Compiler used.

ICL9: Intel C Compiler
VC7: Microsoft C Compiler