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

[kode54]

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.

System specification?

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

You too.

-v -7 -p -z3

CODE

PCM file: Hollister - Bismarck (full 24-96 original unmastered).wav
ALS file: Hollister - Bismarck (full 24-96 original unmastered).als

Encoding... 100% done

Audio format : int / 24 bit / 96000 Hz / 2 ch
Bit rate     : 4608.0 kbit/s
Playing time : 313.1 sec
PCM file size: 180318296 bytes
ALS file size: 96544854 bytes
Compr. ratio : 1.868 (53.54 %)
Average bps  : 12.850
Average rate : 2467.2 kbit/s

Processing took 2431.95 sec (0.1 x real-time)

Also semi-relevant to the topic on compressing 24-bit recordings, only this clip already compresses fairly close to 50% with FLAC. So maybe not.

[jimhaddon]

-7 -p -z3 doesnt work with me either, nor does -7 with -z3 in any combination, just stops immediately.

System spec:

4ghz P4 (stable), 2GB DDR2 Ram, ABit AAX8E Mobo

[jimhaddon]

I have just run a few tests myself...

Using the same WAV file for each test (41,160,044 bytes)

Here are the results in size order

La -high -noseek gave (20,431,442 bytes)
OptimFrog --mode bestnew --seek slow gave a file size of (20,528,612 bytes)
MP4ALS -v-b-p-z3 gave (20,619,064 bytes)
MP4ALS -7 -p gave (21,729,937 bytes)
MP4ALS -z3 -p gave (20,851,202 bytes)
Monkey's audio -insane gave (20,897,352 bytes)

Quite impressive results for -v-b-p-z3, although encoding took 615 seconds, which is 0.4x realtime

This post has been edited by jimhaddon: Dec 31 2005, 11:25

[BoraBora]

System specification?

WinXP SP2
1 Gb RAM
PIV 3.0 Ghz

Note: if I don't include the -v switch, it stops immediately. It seems to hesitate only in verbose mode.

[SirGrey]

System specs:
WinXP SP1
C2600, Chaintech on Intel865PE, 512MB DDR 266

[keytotime]

Xp Sp2
Celeron 2.7 ghz
1gb ram
Soyo 845Pe motherboard

[jimhaddon]

Ok, i did a few more tests,
here are the results in Excel Format.

http://www.hydrogenaudio.org/forums/index....pe=post&id=2000

[Garf]

I emailed the ALS people and it seems you guys were right and I was wrong:

Well, seems to be a problem with the -z1/2/3 modes (backward prediction, similar to Monkey's Audio) which may not work together with other options (except -r#), since they are not intended to do so. Please don't expect the software to recognize all wrong parameter combinations.

Anyway, I would recommend to use -7 -p -t2 for maximum compression (-7 for near max), or  -7 -o100 (-p -t2) for a good  tradeoff in terms of decoding speed (encoding might still be a bit slow).

[jimhaddon]

Well, i just tried out the -7 -p -t2 switches, and they give me less compression than my switches did on the testing files

[keytotime]

Here is my results.
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

This post has been edited by keytotime: Dec 31 2005, 20:57

[rjamorim]

Interesting. Where is Heijden? I need to update my comparison


Edit: I just added the ALS entry to the summary table. As you can see, still lots of blanks to fill:
http://wiki.hydrogenaudio.org/index.php?ti...omparison_Table

I only plan to add an entry to the main article once we (I) have more information on the format.


And I foresee a problem: when mentioning implementation-specific features - stuff like speed, replaygain, etc. - should I focus on the reference or some potentially improved 3rd party solution that might surface in the future?

This post has been edited by rjamorim: Jan 2 2006, 02:58

[keytotime]

You can add for software support, none as of yet. Encoding/Decong Speed slow. Hybrid/lossy None.

This post has been edited by keytotime: Jan 2 2006, 04:01

[Garf]

And I foresee a problem: when mentioning implementation-specific features - stuff like speed, replaygain, etc. - should I focus on the reference or some potentially improved 3rd party solution that might surface in the future?

3rd party solutions. It's not like we judge other formats based on reference software.

[skamp]

• Encoding speed: why is it reported as "slow"?? It's quite fast, on the contrary...
• Seeking: I think it's set by the -r# switch: Random access (multiples of 0.1 sec), -1 = each frame, 0 = off (default)
• Hybrid/lossy: no for now
• Piping: doesn't seem to work for now (but it might be a bug rather than just a lack of feature)

This post has been edited by skamp: Jan 4 2006, 02:41

[jcoalson]

• Seeking: I think it's set by the -r# switch: Random access (multiples of 0.1 sec), -1 = each frame, 0 = off (default)

yeah, lpac was like that too, random access frames had to be specifically requested to get landing sites for seeking. for an apples-to-apples comparison of compression ratio with other codecs, enough of these random access frames should be included. e.g. every FLAC frame is a "random access" frame, and it's probably the same for other lossless codecs.

Josh

[rjamorim]

Encoding speed: why is it reported as "slow"?? It's quite fast, on the contrary...

Hrm... keytotime wrote that. I personally wanted to wait for a benchmark by Heijden or Speek.

Seeking: I think it's set by the -r# switch: Random access (multiples of 0.1 sec), -1 = each frame, 0 = off (default)

Added it, thanks

Hybrid/lossy: no for now

Done

Piping: doesn't seem to work for now (but it might be a bug rather than just a lack of feature)

Right. Even if the official implementation doesn't support piping, someone could probably take the sources and create a simple frontend that supports pipes.

But then again it takes us back to the issue of considering only the reference or third party implementations. I think I'll consider format-specific features - like replaygain and RIFF handling - dependant on the reference or specifications; and other features like piping and encoding and decoding speed up to third parties.

[snookerdoodle]

I'm not sure what I'm looking at here.

They appear to release source for all except for for lpc_adapt.o, containing the "algorithm for an adaptive choice of the prediction order". I'm not at home so I can't try building this on linux yet.

Can someone interpret this for me? Could, say, flac's counterpart (I understand it, too, does a similar predictive algorithm) be included in an "plc_adapt.c" with the same API and still comply with this Standard?

Other than this one seemingly (?) proprietary piece, this would seem to trump all other lossless codecs. The performance doesn't appear outlandish (i.e.: it's usable and in the ballpark with the others) and, of course, plays well with the mpeg folks.

Thanks for any thoughts,

Mark

[keytotime]

I wrote slow because the default takes longer than Wavpack at -h, Flac -8, and optimfrog. At anything else but default, the compresion takes an insane amount of time at runs between .2x and .1x . And decoding is tied pretty close to encoding time.

This post has been edited by keytotime: Jan 5 2006, 03:40

[Synaptic Line No...]

• Multi-channel / multi-track support for up to 65536 channels (including 5.1 surround)

Only 65536? Darn, I wanted 228000000000000 channels!

[Synaptic Line No...]

Pretty cool. The big question now is who will adopt it... Let's hope Apple Lossless was just a stop-gap solution

I think most people say that FLAC is the archivist's codec, from the old lossless survey results, and people's comments, because it is completely free, has decent speed and compression ratio's, but mostly because it's GPL.

I don't see this changing much in that area, because this is probably patented.

[extesy]

I don't see this changing much in that area, because this is probably patented.

Well, MP3 is also patented, but that doesn't prevent existense of LAME

[stephanV]

The difference is that MP3 did not have much competition at the time. However, the succes of any MPEG format is much more related to adoptation by companies, than that it is to patent issues.

[skamp]

I wrote slow because the default takes longer than Wavpack at -h, Flac -8, and optimfrog. At anything else but default, the compresion takes an insane amount of time at runs between .2x and .1x . And decoding is tied pretty close to encoding time.

I don't know what you did, but I certainly don't get such results (all done in RAM with an Athlon XP2500+ Barton - the song is 230s long):

$ time { wavpack -h -o foo.wv 04\ -\ Souvenir.wav ; }
real 0m6.306s (36.5x)
user 0m5.915s
sys 0m0.214s

$ time { flac -o foo.flac --best 04\ -\ Souvenir.wav ; }
real 0m21.282s (10.8x)
user 0m20.173s
sys 0m0.249s

$ time { ofr --encode 04\ -\ Souvenir.wav --output foo.ofr ; }
real 0m15.488s (14.9x)
user 0m14.701s
sys 0m0.176s

$ time { mp4als -v 04\ -\ Souvenir.wav foo.als ; }
real 0m7.064s (32.6x)
user 0m6.686s
sys 0m0.166s

Decoding:

$ time { wvunpack -mq foo.wv -o bar.wav ; }
real 0m6.293s (36.5x)
user 0m5.795s
sys 0m0.197s

$ time { flac --decode --silent -o bar.wav foo.flac ; }
real 0m1.760s (130.7x)
user 0m1.611s
sys 0m0.107s

$ time { ofr --decode foo.ofr --output bar.wav ; }
real 0m11.498s (20.0x)
user 0m10.939s
sys 0m0.152s

$ time { mp4als -x foo.als bar.wav ; }
real 0m3.078s (74.7x)
user 0m2.652s
sys 0m0.303s

Sorry for all the edits. I remembered flac was the only encoder on my system that I compiled without optimization, so I recompiled it. I also added OptimFROG.

This post has been edited by skamp: Jan 5 2006, 13:49

[keytotime]

Try Mp4 -7 -P or Mp4 -7 -p -t2

This post has been edited by keytotime: Jan 5 2006, 16:03

[skamp]

Try Mp4 -7 -P or Mp4 -7 -p -t2

That's not the default settings, which is what you based your comment on. And I already have posted results of an encoding with those settings earlier in this thread. I did use --best with FLAC here because... well, now that I think of it, I don't know. I should use default settings with it as well. Same for WavPack. Anyway, it does show that the encoder is not slow at all. Those settings you mention are extreme ones, comparable both in encoding speed and compression to wavpack -hx6.

This post has been edited by skamp: Jan 5 2006, 17:55