How does LPAC compare to FLAC and MA? Options

[sapnho]

Just read about another lossless codec here LPAC Homepage

and I wonder if anybody has done a test comparing the algohythms yet?

This post has been edited by sapnho: Jan 10 2004, 09:48

[spase]

AFAIK, LPAC is older and not as good as the codecs you mentioned. Not 100% sure tho.

[Garf]

Years ago it was reasonably popular but had trouble really catching on because there were no opensource decoders. When other formats with better performance and free decoders arrived, it was quickly replaced.

I find the announcement about MPEG4 on the webpage quite surprising, hence.

[nOmAd]

Originally people in MPEG want to have a scalable lossless audio technology so that it could do more work than simple compression. However during the development process some guys keep asking for a simple "lossless only" algorithm for their archiving system. This leads to the MPEG ALS work. Since LPAC is the only submission for this category it naturally becomes the "best"

[menno]

The compression method used is definately not LPAC as we know it now, it has been improved a lot. And in tests proved to give better compression then MAC and much faster encoding speed.

Menno

[Speek]

The compression method used is definately not LPAC as we know it now, it has been improved a lot. And in tests proved to give better compression then MAC and much faster encoding speed.

Whoa, I'ld like to see that Do you know when a version of this compressor will be available to the public?

[menno]

Not really, I believe it is still in draft stage at MPEG.

Menno

[nOmAd]

The compression method used is definately not LPAC as we know it now, it has been improved a lot. And in tests proved to give better compression then MAC and much faster encoding speed.

Menno

It is no longer fast at all when you turn on the BGMC in its entropy coder for best compression result and still slight inferior to MAC for 48/16 signals... Anyway it is at the draft stage and may be further improved once it is finalized.

This post has been edited by nOmAd: Jan 10 2004, 17:59

[menno]

It is no longer fast at all when you turn on the BGMC in its entropy coder for best compression result and still slight inferior to MAC for 48/16 signals... Anyway it is at the draft stage and may be further improved once it is finalized.

Hehe, seems that I was reading the speed tables from the verification report wrongly. It said "speed", so I thought higher was better

Menno

[rjamorim]

I believe they aren't after Monkey's efficiency (speed vs. compression), since that would certainly require optimized Assembly code and would make multiplatform interoperbility a nightmare.

[jcoalson]

see also

[Garf]

I believe they aren't after Monkey's efficiency (speed vs. compression), since that would certainly require optimized Assembly code and would make multiplatform interoperbility a nightmare.

That's irrelevant to the standard. Once it's set, there's nothing holding you to write an ASM implementation of it.

[rjamorim]

That's irrelevant to the standard. Once it's set, there's nothing holding you to write an ASM implementation of it.

But an implementation meant for multiplatform interoperability (probably C/C++) would be painfully slow without using ASM. That is not interesting for MPEG.

It's all fine and dandy with Monkey's Audio because it's mostly meant for usage in x86, but MPEG standards are supposed to run from cell phones all the way up to mainframes. An implementation meant for multiplatform usage would have to worry about writing optimized assembly for each one of these platforms.

This post has been edited by rjamorim: Jan 11 2004, 14:41

[dev0]

So why aren't they using FLAC then?
(Sorry, just had to ask)

dev0

[Garf]

An implementation meant for multiplatform usage would have to worry about writing optimized assembly for each one of these platforms.

Not necessarily. You can have some in C and the more interesting ones rewritten into assembler.

If the C one is already competitive, that bodes very well for ASM versions.

[Garf]

So why aren't they using FLAC then?
(Sorry, just had to ask)

dev0

Much worse compression ratio. And FLAC wasn't submitted apparently.

[rjamorim]

So why aren't they using FLAC then?
(Sorry, just had to ask)

Did anyone submit FLAC as an option?

The MPEG doesn't go after developers. They publish a call for technologies for the next issue they want to tackle, and then developers submit solutions to that issue. If nobody submitted FLAC (there have been 7 lossless audio coder submissions, IIRC), there's no way MPEG themselves would go after Josh asking him to use his technology.

[rjamorim]

If the C one is already competitive, that bodes very well for ASM versions.

Well, Monkey's Audio C only isn't very competitive, and that's what was being discussed (if they would go for Mac's efficiency)

[Garf]

If the C one is already competitive, that bodes very well for ASM versions.

Well, Monkey's Audio C only isn't very competitive, and that's what was being discussed (if they would go for Mac's efficiency)

Sorry, I misunderstood. The current draft seems to be competitive to MA, and doesn't use ASM. So I find it pretty interesting.

[nOmAd]

If the C one is already competitive, that bodes very well for ASM versions.

Well, Monkey's Audio C only isn't very competitive, and that's what was being discussed (if they would go for Mac's efficiency)

Sorry, I misunderstood. The current draft seems to be competitive to MA, and doesn't use ASM. So I find it pretty interesting.

yes but once it goes to MPEG there is nothing to prevent it from becoming very bulky and clumsy later on ... (just think about the AAC main )

[jcoalson]

So why aren't they using FLAC then?
(Sorry, just had to ask)

dev0

Much worse compression ratio. And FLAC wasn't submitted apparently.

I haven't seen any comparison between FLAC and the proposal, do you have a link? The compression difference between LPAC and FLAC is not great but probably some improvements have been made (though it's hard to tell because LPAC was always closed).

I never knew about the RFC and no one approached me about it either. nOmAd said it was the only submission? If that's true you'd think the MPEG guys would do a simple search for lossless audio to see what was out there (pretty hard to miss FLAC).

Anyway, we all know how codec merits are just one of many factors that lead to acceptance in MPEG. I'd expect playing ball w.r.t. patents/licensing/etc is more important so maybe I wouldn't have been interested anyway.

There are elements of the proposal that are in FLAC also, and LPAC was developing at the same time, and FLAC source was always open. It will be interesting to see how much get claimed in the patent work for for ALS.

Josh

This post has been edited by jcoalson: Jan 11 2004, 19:20

[rjamorim]

I never knew about the RFC and no one approached me about it either.

Here is the call for proposals:
http://www.tnt.uni-hannover.de/project/mpe...blic/w5040.html

It was mentioned at the MPEG site and also at the MPEGif mailing lists. These are the usual places developers go to find news about MPEG.

nOmAd said it was the only submission?  If that's true you'd think the MPEG guys would do a simple search for lossless audio to see what was out there (pretty hard to miss FLAC).

There were at least seven submissions, according to Tilman's site:

By December 2002, seven companies submitted one or more codecs which met the basic requirements.

Again, the MPEG doesn't go after developers. Interested developers go after them after the call for proposals is issued.

Anyway, we all know how codec merits are just one of many factors that lead to acceptance in MPEG.  I'd expect playing ball w.r.t. patents/licensing/etc is more important so maybe I wouldn't have been interested anyway.

That's wrong. In the past there have been reportedly political reasons for choosing of this spec over another (although that is now in doubt too since a pratical reason has been discovered to a spec that seemed political only. That is, the MP3 filterbank model)

Nowadays, reportedly, only efficience matters. Patents also aren't sine-qua-non - we have Structured Audio that is completely unpatented and public domain. Also, I did a limited research at the DPMA (German Patent Office), and could find no patent owned by "Liebchen". But my knowledge of German is very bad and maybe I did the search wrong, I don't know.

Regards;

Roberto.

This post has been edited by rjamorim: Jan 11 2004, 23:00

[nOmAd]

It is a waste for a developer who forgets to file something somewhere for his submission to MPEG, which is also unlikely since MPEG actvity is very expensive (both time and money). and even he does during the MPEG development process other guys may try to put their stuff in to "improve" it so it is almost impossible to have a free standard frankly speaking. The structured audio may be the only exception though.

There were at least seven submissions, according to Tilman's site:

By December 2002, seven companies submitted one or more codecs which met the basic requirements.

There are some other submissions that go to the scalable lossless category.