Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: How does LPAC compare to FLAC and MA? (Read 10385 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

How does LPAC compare to FLAC and MA?

Just read about another lossless codec here LPAC Homepage

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

How does LPAC compare to FLAC and MA?

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

How does LPAC compare to FLAC and MA?

Reply #2
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.

How does LPAC compare to FLAC and MA?

Reply #3
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" 

How does LPAC compare to FLAC and MA?

Reply #4
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

How does LPAC compare to FLAC and MA?

Reply #5
Quote
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?

How does LPAC compare to FLAC and MA?

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

Menno

How does LPAC compare to FLAC and MA?

Reply #7
Quote
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.

How does LPAC compare to FLAC and MA?

Reply #8
Quote
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

How does LPAC compare to FLAC and MA?

Reply #9
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.

How does LPAC compare to FLAC and MA?

Reply #10
see also

How does LPAC compare to FLAC and MA?

Reply #11
Quote
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.

How does LPAC compare to FLAC and MA?

Reply #12
Quote
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.

How does LPAC compare to FLAC and MA?

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

dev0
"To understand me, you'll have to swallow a world." Or maybe your words.

How does LPAC compare to FLAC and MA?

Reply #14
Quote
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.

How does LPAC compare to FLAC and MA?

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

dev0

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

How does LPAC compare to FLAC and MA?

Reply #16
Quote
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.

How does LPAC compare to FLAC and MA?

Reply #17
Quote
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)

How does LPAC compare to FLAC and MA?

Reply #18
Quote
Quote
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.

 

How does LPAC compare to FLAC and MA?

Reply #19
Quote
Quote
Quote
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  )

How does LPAC compare to FLAC and MA?

Reply #20
Quote
Quote
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

How does LPAC compare to FLAC and MA?

Reply #21
Quote
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.

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

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

How does LPAC compare to FLAC and MA?

Reply #22
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.

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