MPEG-4 Audio Lossless: final specifications, ...and first encoder is available! Options

[David Nordin]

for the amount of muscles ALS is throwing at the problem the results are a bit disappointing.

this is a reference encoder - keep that in mind. It will not reflect perfomance once this has been adopted by the companies interested in this new exciting standard.

[Borisz]

for the amount of muscles ALS is throwing at the problem the results are a bit disappointing.

this is a reference encoder - keep that in mind. It will not reflect perfomance once this has been adopted by the companies interested in this new exciting standard.

And given that, the results are already impressive, especially for DVD-Audio.

[Garf]

Does anybody know what patents are being used in MPEG-4 ALS and what the licensing terms are?

That won't be known for quite a while. The MPEGLA does a call for patents, and tries to get everyone who has one that applies to MPEG4 ALS to agree on a common licensing agreement.

[pest]

this is a reference encoder - keep that in mind. It will not reflect perfomance  once this has been adopted by the companies interested in this new exciting standard.

this is not a lossy framework as mp3 for example so i doubt that there will
be large improvements as the decoder has to be the same and tweaking
would break it. anyway lets see.

[Garf]

this is a reference encoder - keep that in mind. It will not reflect perfomance  once this has been adopted by the companies interested in this new exciting standard.

this is not a lossy framework as mp3 for example so i doubt that there will
be large improvements as the decoder has to be the same and tweaking
would break it. anyway lets see.

In terms of compression ratio, I would agree that significant improvement is unlikely. But in terms of speed, I would expect massive improvements.

[jcoalson]

here

is it me or is the source code zip missing lpc_adapt.cpp?

[Garf]

here

is it me or is the source code zip missing lpc_adapt.cpp?

readme.txt is called like that for a reason

[jcoalson]

heh, yeah I already built a linux binary. the readme doesn't say why it's missing though.

I don't see why all the fuss about encoding speed, it's the decode that matters. on my machine, default ALS decodes about twice as slow as default FLAC. it will be nice to see Hans' table updated for the big picture.

Josh

[guruboolez]

heh, yeah I already built a linux binary.  the readme doesn't say why it's missing though.

I don't see why all the fuss about encoding speed, it's the decode that matters.  on my machine, default ALS decodes about twice as slow as default FLAC.  it will be nice to see Hans' table updated for the big picture.

Josh

Yes, I agree: current speed is disappointing. Especially for higher than defaut compression level:
-z1 = decoding time = x0.9 on a laptop (AMD Athlon XP 2000+) and ratio is not impressive compared to extreme formats such as OptimFROG, LA or even MAC -c4000/5000 which are clearly less painful on the decoding side (and encoding too).

-7 = decoding time = x9 on the same computer. For such slow but acceptable (for PC) speed, ratios have nothing extraordinary.

For default setting, I was able to reach x60, whereas flac and WavPack -f could both reach x120.

This post has been edited by guruboolez: Dec 29 2005, 22:54

[keytotime]

Quick question, which app can play the als files?

[BoraBora]

A quick and dirty test. Timings are not accurate, I did a lot of work on my PC while encoding/decoding.



PIV 3.0 Ghz.

This post has been edited by BoraBora: Dec 30 2005, 13:43

[Garf]

How slow and how compact is -7 -p -z3 ?

Does it beat the most insane OptimFROG lines?

[keytotime]

-7 -p -z3 does not work.
-7 -p works.
-z3 -p works.

OptimFrog --mode bestnew --seek slow 40,418,314 bytes
Mp4 -7 -p -t2 40,756,102 bytes 5123.75 sec (0.1 x real-time)
Mp4 -7 -p 40,770,071 bytes (2587.11 sec) Decoding 140.2 seconds
Mp4 -z3 -p 41,186,238 bytes Decoding 2971.78 Seconds
Wavpack -h 42,901,452 bytes
flac -8 44,255,687 bytes
wav 100,900,844 bytes

close but the frog still wins.

This post has been edited by keytotime: Dec 31 2005, 17:33

[Garf]

-7 -p -z3  does not work.

Sure it does!

C:\work>mp4alsrm16 -7 -p -z3 metal.wav

C:\work>mp4alsrm16 metal.wav metaldft.als

C:\work>dir *.als
Volume in drive C has no label.
Volume Serial Number is 284A-BB0F

Directory of C:\work

30/12/2005 15:35 32.952.320 metal.als
30/12/2005 15:37 34.826.981 metaldft.als
2 File(s) 67.779.301 bytes
0 Dir(s) 5.524.795.392 bytes free

[keytotime]

-7 : Set parameters for optimum compression (except LTP, MCC, RLSLMS)
-z#: RLSLMS mode (default = 0: no RLSLMS mode,  1-quick, 2-medium 3-best )

[Garf]

-7 : Set parameters for optimum compression (except LTP, MCC, RLSLMS)
-z#: RLSLMS mode (default = 0: no RLSLMS mode,  1-quick, 2-medium 3-best )

What are you trying to say here?

[keytotime]

That the program says that it cann't work. -7 can not work with RLSLMS mode and -z3 set's RLSLMS mode.

[Garf]

That the program says that it cann't work. -7 can not work with RLSLMS mode and -z3 set's RLSLMS mode.

You are wrong, it doesn't say it cannot work. -7 sets the parameters to the optimum, EXCEPT the ones for LTP, MCC and RLSLMS. (I guess because the effect on speed). But you can still manually set those to the optimum values.

I already showed you can, and BoraBora's result shows that they have effect.

[keytotime]

*slap's himself with a trout*
Sorry.

[miros]

-7 = decoding time = x9 on the same computer.

Interesting, your decoding of a -7 file is faster than mine even though I have a faster cpu. I tried some other files and it looks like decoding speed is very variable. I made a graph showing the variability, decoded is whole album (507MB). However, decoding speed for a file encoded with default settings is pretty stable.

[BoraBora]

How slow and how compact is -7 -p -z3 ?

Does it beat the most insane OptimFROG lines?

It may be. For some reason, I can't make work "-7 -p -z3". Encoding stops after a couple of seconds. Weird.

I tried "-s2" and "-s2 -p", though :

CODE

186661407     46,36%   "-p -s2"
186886405     46,42%   "-s2"
186900432     46,42%   "-p"
187611042     46,60%    default

[Garf]

It may be.  For some reason, I can't make work "-7 -p -z3". Encoding stops after a couple of seconds. Weird. 

Does it really stop or is it just insanely slow?

I would expect results from -7 -z3 to be better than all others you tried, if you can't get -7 -p -z3 to work.

[BoraBora]

Does it really stop or is it just insanely slow?

No, it stops and the prompt comes back. I have no error message, though I'm in verbose mode. Nothing. It starts then seems to change its mind and stops. Too much work, maybe? I'll try again on a small sample.

Edit : well, same thing on a single short track, with or without -v. I don't understand.

This post has been edited by BoraBora: Dec 30 2005, 16:28

[keytotime]

yah that's what happen's to me to.

[SirGrey]

For me:
-7 switch does not work with -z3 switch. Or wise versa
-z3 alone works.

If somebody isn't lazy enought to find, what switches -7 sets or resets, then he will be able to find the specific switch that doesn't work with -z3...

EDIT: BTW, for me encoding with -7 -z3 is ended imidiately, not after some seconds...

This post has been edited by SirGrey: Dec 31 2005, 03:06