System specification?


You too.

-v -7 -p -z3


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.

-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

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

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.

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

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

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

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

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

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

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

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?

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

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

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

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

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



Added it, thanks



Done



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.

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

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.

Only 65536? Darn, I wanted 228000000000000 channels!

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.

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

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.

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


Decoding:


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.

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.

You can look at it from another perspective - companies didn't have much of a choice than giving support for mp3.

Also the adoption of a loseless format would mean higher bandwith use. 4mb verus 30mb.

Average connection speed today is much faster than it was at the time when MP3 was invented.

But think in the servers point of view. I don't want to have an 10 times bigger bill if the lossy formats sound just fine. Lossy formats won't disapear soon. Images are still encoded in jpg format for example.

Apart from a smaller filesize, what's so exciting about ANOTHER lossless format? Are there really not enough different audio-formats out there, not just to mention all the different lossless formats????

Personally I've given vorbis a try, but I forced myself back to MP3 for compatibility reasons.

It's standardized? It has better performance for high bitrates/sampling rates? It supports good rates with float data?

Speaking as a person with a significant amount of time and effort invested in a CD collection that is now all on my hard drive as flac files...

Standards. And the hope of the benefits of standards.

Yes, there ARE too many lossless formats already. And none of them has been adopted by everyone, since none has a clearly compelling advantage.

A format being accepted as a standard by a major industry group is an advantage. If that fact causes it to be supported by Most Major Platforms (i.e.: supported out of the box by OS-X, Windows, and Unix variants such as Linux, supported out of the box on i-Pod and many MP3 players).

If that happened, I'd gladly take the time (ok, it would just be a script this time) to convert my flac files to THAT format.

*If* that happened...

Mark

"The nice thing about standards is that there are so many of them to choose from."
-- Andrew S. Tanenbaum

Is there a directshow/winamp/etc decoder available?

Tested the reference encoder on my benchmark, second place after OptimFROG:
http://uclc.info/lossless_audio_compression_test.htm

minor nit: the codec is licensed bsd-like:

Hey, guys, can anyone tell me what the command-line settings for EAC are?..
Or there are no such settings at all?..

Seems like there is a bug fixed version and a new release expected for this month according to T. Liebchen.

http://www.nue.tu-berlin.de/forschung/proj....html#downloads

Just out of curiosity, what does S in ALS stand for? It's "s" in "lossless"?

\"MPEG-4 Audio Lossless Coding (ALS)\"

are you saying it's a recursive acronym? I don't think so.

form wiki

What are you trying to say?

MPEG-4 ALS stands for Audio Lossless Coding
or there is another explanation of MPEG-4 ALS

Yes, we know what it stands for, but where does the ALS come fron?

Audio Lossless S...?

I guess it's probably the S from Lossless as the original poster also thought.

Considering
Audio Lossless Coding = ALS
and
Scalable Lossless Coding = SLS,
perhaps LS stands for "Lossless" here. Still.... it could have been ALC and SLC just like
Advanced Audio Coding = AAC
and
Advanced Video Coding = AVC.

The news release, "MPEG-4 ALS (audio lossless coding)" is ready says "14496-3 3rd ED AMD 2 (ALS): MPEG-4 audio 3rd edition amendment 2. It is usually called as ALS." in its <Terminology> section, but why it is "usually called" so is unclear.

Just a random interest

MPEG-4 Audio Lossless Coding (ALS) Standard

this is only my theory

I think that it is Audio-LS (lossless), in a similar naming to JPEG-LS

The promised new release is now out. Along with a new interesting promise as well (a WinAmp plugin in the next few days).

As far as I can see, only a small bugfix. Still no sign of MP4 embedding or at least a reference file for that (was promised months ago).

They are going to release a Winamp plugin before they finish MP4 embedding? Yeah, let's spread those .ALS files instead of proper containers. Perhaps we can even tack ID3v2 on them, hah!

Please tell me it ain't so.

Not the most popular format around at the moment, but, in case someone is interested:

RM18 (available 22 September 2006): Will additionally include full MP4 file format support