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: Latest MPEG-4 Audio Lossless Coding (ALS) (Read 28268 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Latest MPEG-4 Audio Lossless Coding (ALS)

Latest MPEG-4 Audio Lossless Coding (ALS) available now
http://www.nue.tu-berlin.de/forschung/proj...ess/mp4als.html

But foobar2000 v0.9.1 does not support the encoded file yet..
Winamp support will be available by end of April as indicated in official website.

[Edit]
2006-04-28
Winamp plugin available now.  It's strongly advised to read Garf's comment (post 14) in this thread before you decide to use it to convert all your music into this loosless format.
Note: Winamp plays fine but not tagging available.... When I click to show info, it only popup a msg window rather than a tagging dialog.  You then know why the information in the above link is important to know

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #1 –
I look forward to this ALS lossless international standard. That way software (should) work interoperably and we should have a standard lossless file format that all hardware and software (including PC, Mac and Linux) can agree on and whose files shouldn't become obsolete in the future. It is unfortunate that it contains patented routines. We shall see if Adobe Audition, Nero, Easy Media Creator, iTunes, Easy CD-DAE, RealPlayer and others start supporting this ALS lossless MPEG 4 audio standard. Now if Microsoft and Apple embraced this in their respective media players (WMP 11/10 and Quicktime 7), boy would this thing take off.
 

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #4 –
Quote from: kurtnoise on
Quote from: goodnews on

It is unfortunate that it contains patented routines.

So, what's the problem ? Most routines nowadays are patented...

Patents can usually cause someone wishing to include the code/routines to have to pay someone licensing fees/royalties to legally use the code in their software or hardware product. Unlike FLAC and others that claim to use no patented code/routines, this may cause some software/hardware vendors to bypass including ALS audio format support in their products due to the expense/cost of licensing these patents.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #5 –
Quote from: goodnews on
Patents can usually cause someone wishing to include the code/routines to have to pay someone licensing fees/royalties to legally use the code in their software or hardware product. Unlike FLAC and others that claim to use no patented code/routines, this may cause some software/hardware vendors to bypass including ALS audio format support in their products due to the expense/cost of licensing these patents.

On the other hand, a clear patent pool/fees can be considered as a kind of security, unlike some other solutions  with unknown situation regarding patents.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #6 –
Quote from: Gabriel on
On the other hand, a clear patent pool/fees can be considered as a kind of security, unlike some other solutions  with unknown situation regarding patents.

Yes, I guess you are right about that Gabriel. We could all look at how the MP3 format and patent debacle has warped over the years, from developers thinking it was free to use MP3 routines initially to now many being "asked" to license FhG/others for patents behind technology that is claimed to be used in encoding and/or playback of MP3 files.

I guess I like the idea of having "peace of mind" (or as you put it, security) that the ALS format is an ISO approved standard, all patent issues/pools should be covered, it has a realtively good compression rate/file size for lossless files, and should be around for many years to come. It sure took its time to get approved as a standard and out to the world (I thought it was to be released/commercially available almost 1 1/2 years ago), but I guess it should be worth the wait to have a International standard format that will work on all platforms.

Now it will be up to people to develop a universally accepted tagging standard for these standalone ALS files and also put out the specs and code for including ALS files in an MP4 container file. I will be watching to see how many software (and hardware) developers embrace/support the ALS audio format, before I make a decision to switch my master audio files over from FLAC to ALS.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #7 –
About hardware players:

does someone know if different complexity profiles are already defined (like MPEG-4 ASP/AVC have)? Because MPEG-4 ALS is in my knowledge the only format which could be very fast and very slow on the decoding side. I can't imagine any hardware player supporting yet the strongest profiles. And if hardware players couldn't support all MPEG-4 ALS encodings, a clear scale should be designed to avoid confusion in the future.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #8 –
Nothing is defined as far as I know, although there was talk about it.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #9 –
i checked the source, and they implemented a
lz77 coder as fallback...nice one 

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #10 –
That is completely wrong.

The LZ77 coder (actually it's an LZP variant if I remember correctly) is used for compression of parts of floating point numbers, is only used when dealing with float input data, and exists in support of and not in replacement of the normal methods.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #11 –
Quote
The LZ77 coder (actually it's an LZP variant if I remember correctly) is used for compression of parts of floating point numbers, is only used when dealing with float input data, and exists in support of and not in replacement of the normal methods.


the use as a fallback was just an estimate, looked at it for 5 minutes
but after looking at it again it donesn't seem to be LZP.
Sorry for the mistake.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #12 –
Any chances of a Garf optimized build or does this one already contain his "speedups" please?
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #13 –
I have become completely disinterested in this format now that it is clear they will not properly support the MP4 container but instead prefer to promote spreading of raw ALS files, which undoubtely will lead to a mess such as ALS+ID3V2 or ALS+APE2 or whatever, completely voiding any purpose of existance this format ever might have had.

I would strongly suggest everyone to stay away from ALS and instead use a format such as Wavpack of FLAC.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #14 –
I see and agree, I'm a WavPack user already anyway, it was just for test purposes, thanks.
WavPack 5.6.0 -b384hx6cmv / qaac64 2.80 -V 100

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #15 –
Quote from: Garf on
I have become completely disinterested in this format now that it is clear they will not properly support the MP4 container but instead prefer to promote spreading of raw ALS files, which undoubtely will lead to a mess such as ALS+ID3V2 or ALS+APE2 or whatever, completely voiding any purpose of existance this format ever might have had.
This just seems bizarre to me.  I don't pretend to understand the situation at all, but when I see "MP4ALS" I crazily assumed that an MP4 container was a given.

Is it possible that it is just early days, or are you quite certain that they have no intention to deal with the container at some point in the future?

I agree though, the idea of confusing what should have been a good, solid standard with ID3v2 and/or APEv2 is plain stupid.
I'm on a horse.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #16 –
I can only see that:

1) Despite promises months ago, there is no further information about MP4 embedding, no example/reference files and no support in the software itself. It might be possible to theorethically determine how it should be done from the standard, but realistically I don't want to do this without any reference to check my implementation against. And I'm sure that anyone else considering support will have the same problem.

2) They apparently considered making a Winamp plugin (supporting only .ALS and only supporting a subset of the possible encoding modes) a higher priority.

Now, people will want to tag those .ALS files for use with Winamp, and god knows what happens next. One would think they would have learned from the experience with MP3...

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #17 –
Quote from: Garf on
...it is clear they will not properly support the MP4 container but instead prefer to promote spreading of raw ALS files...

This was the problem when I initially tested it. I was getting an error about file not found because the output was .ALS instead of .MP4. It was purely my error when assuming that a binary dubbed MP4ALS would output  its namesake. It's too bad it doesn't (yet) since it is made to handle both 32-bit float and multichannel.
"Something bothering you, Mister Spock?"

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #18 –
Quote from: goodnews on
I look forward to this ALS lossless international standard. That way software (should) work interoperably and we should have a standard lossless file format that all hardware and software (including PC, Mac and Linux) can agree on and whose files shouldn't become obsolete in the future. It is unfortunate that it contains patented routines. We shall see if Adobe Audition, Nero, Easy Media Creator, iTunes, Easy CD-DAE, RealPlayer and others start supporting this ALS lossless MPEG 4 audio standard. Now if Microsoft and Apple embraced this in their respective media players (WMP 11/10 and Quicktime 7), boy would this thing take off.
Agreed.  Lossless audio is becoming more reasonable in filesize these days, to the point that I would be happy to use it on a more regular basis.  My point of interest is muxing it into MP4.  I do NLE on short videos, so keeping a lossless H.264 + ALS master is really appealing, especially when you consider how efficient these standards are.  I was very impressed with the reference software, it would be great to see someone pick it up as a project and tweak it, maybe even improve the efficiency a bit.

Quote from: Garf on
I have become completely disinterested in this format now that it is clear they will not properly support the MP4 container but instead prefer to promote spreading of raw ALS files, which undoubtely will lead to a mess such as ALS+ID3V2 or ALS+APE2 or whatever, completely voiding any purpose of existance this format ever might have had.

I would strongly suggest everyone to stay away from ALS and instead use a format such as Wavpack of FLAC.
I appreciate your concerns, in a way it's similar to how I feel about H.264 in AVI
But lets look on the positive side, before shooting it down altogether.  They may well promote spreading of .ALS files, but it's the end user that will have the most impact in the end.  What we need is a working Directshow decoder, and for ALS support to be added in GPAC's MP4box (and parsing in Haali's splitter), and you are already part way there.

Why do I say that it's the end user that has the most impact?  Well look back to encoding a few years ago.  People were storing MPEG-4 SP in AVI (via DivX 3.11 etc); at that time AVI was familliar to them, and MP3 was good enough.  There wasn't enough incentive (or tools available, this is the important part) to use MP4 for instance.  People got used to encoding with DivX and storing in AVI.  As DivX progressed and they introduced B-frames, they obviously didn't want to jump ship to MP4 because they would huge amounts of people, and lose custom.  Naturally the solution was to hack B-frames into AVI to keep the end user happy.

If you look around now, you will even find hardware MPEG-4 ASP players that support ASP in AVI, and some of these do not even mention MP4!  How crazy is that?  The standard container is not even supported!

Now we have H.264.  The information about the required hacks for B-frames in AVI/VfW has become more widely known (among encoders), and H.264 in AVI is generally accepted as a bad thing?, so encoders now are using MKV or MP4.  When people (we encode fanubs) question the switch from ASP in AVI to H.264 in MP4/MKV, we give them a basic understanding of what happens or why it is bad, sure this doesn't matter to most people, but they also get the benefit of Vorbis or AAC as opposed to MP3, maybe chapters too.  Sometimes we may even tell them a little white lie, you have to be cruel to be kind  .  The basic notion is that we learned from our mistakes and we want to do things "properly" now, and even this may help have an effect on the industry.  As I'm sure you know, Nero's MP4/H.264/AAC abilities have also helped spread the "word" a good deal.

AFAIK, itunes wraps it's AAC encodes in MP4 and just changes the extension a bit, as a result MP4 files are being spread.

In short, since no one else is promoting ALS in MP4, we can do it ourselves providing the tools and support is there.  Word soon gets around.

An encoder already exists (no matter how unoptimised it may or may not be), all that's needed now is a directshow decoder (something that would eventually be available in FFDShow would be awesome), parser (maybe Haali might be interested once muxing exists with MP4box), and of course the muxing to MP4 itself.  It is an inconvienience that they do not have direct MP4 output, but it's not the end of the world having to mux it; or if someone did pick up an ALS project, maybe direct MP4 output could be incorporated there.


Quote from: Garf on
I can only see that:

1) Despite promises months ago, there is no further information about MP4 embedding, no example/reference files and no support in the software itself. It might be possible to theorethically determine how it should be done from the standard, but realistically I don't want to do this without any reference to check my implementation against. And I'm sure that anyone else considering support will have the same problem.

2) They apparently considered making a Winamp plugin (supporting only .ALS and only supporting a subset of the possible encoding modes) a higher priority.

Now, people will want to tag those .ALS files for use with Winamp, and god knows what happens next. One would think they would have learned from the experience with MP3...
With regards to your first point, I assume that from this, that MPEG-4 ALS will be stored in the same or similar way to AAC when it comes to containing it in MP4 (though this really is an assumption, so don't take it too seriously).  As you can see, it's an amendment to 14496-3 (which covers muxing of audio I believe).
http://www.iso.org/iso/en/CatalogueDetailP...5&ICS2=40&ICS3=

As for the second point.  I really don't know what they was thinking making a Winamp plugin first, a Directshow decoder would have been so much more useful.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #19 –
Quote from: Zero1 on
---snip---
Why do I say that it's the end user that has the most impact?  Well look back to encoding a few years ago.  People were storing MPEG-4 SP in AVI (via DivX 3.11 etc); at that time AVI was familliar to them, and MP3 was good enough.  There wasn't enough incentive (or tools available, this is the important part) to use MP4 for instance.  People got used to encoding with DivX and storing in AVI.  As DivX progressed and they introduced B-frames, they obviously didn't want to jump ship to MP4 because they would huge amounts of people, and lose custom.  Naturally the solution was to hack B-frames into AVI to keep the end user happy.

If you look around now, you will even find hardware MPEG-4 ASP players that support ASP in AVI, and some of these do not even mention MP4!  How crazy is that?  The standard container is not even supported!
---snip---

---snip---
As for the second point.  I really don't know what they was thinking making a Winamp plugin first, a Directshow decoder would have been so much more useful.
---snip---


Hi Zero1

The role of the DivX developers cannot be overlooked in the propagation of DivX in AVI as an usable proposition. Looking at the group developing MP4ALS and referring to Garf's observations, I am not sure if they are too interested in making it workable using the MP4 container, leave alone a hack. This kind of reduces the appeal in using MP4ALS right now. Of course, this is just my personal view 

The other thing is the decoder for Winamp. Not being able to tag it from within Winamp will definitely put off many people. Even if they decide to try the format, this fact might leave a bitter taste and they may not adapt to the format easily later, even if the bugs are ironed out.

In short, they must adhere to the MP4 container standard. I guess this will be advatageous to all concerned. If what Garf has said is true, the format might have a rough ride ahead.
Reason is immortal, all else mortal
- Pythagoras

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #20 –
Quote from: Zero1 on
An encoder already exists (no matter how unoptimised it may or may not be),


I actually already posted an optimised encoder for ALS here, shortly after the format was finalized. Waste of precious time, it seems now.

Quote
With regards to your first point, I assume that from this, that MPEG-4 ALS will be stored in the same or similar way to AAC when it comes to containing it in MP4 (though this really is an assumption, so don't take it too seriously).  As you can see, it's an amendment to 14496-3 (which covers muxing of audio I believe).
http://www.iso.org/iso/en/CatalogueDetailP...5&ICS2=40&ICS3=


I don't want to incorporate or push for support for this without anything to check implementations against. 1 reference file might be enough to start with.

The most important advantage of ALS compared to FLAC/Wavpack is that ALS is a standard, but how much of that is left if you risk incompatible implementations?

The fact that publishing a (crippled!) Winamp plugin has higher priority than ensuring proper interoperability is a sure thing something is rotten in MPEG 4 ALS land.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #21 –
I have just added MPEG-4 ALS (RM17 version), among other updates, on my page.

Default results are very similar to LPAC which is disappointing. The three other switch settings were suggested by Garf here.

The bare -7 switch on album "platina" gave 64.24%, compressed at 0.4x speed, and decompressed at 4.9x speed. So compression is too slow to fit in the graph, but just wanted to mention this anyway!

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #22 –
Excellent! Thank-you very much, Hans

Now I'll update the Wiki comparison

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #23 –
The vertical "bend" in the compression graph going from -a -o30 to default (= -o10) made me suspicious. It turned out after some attempts that adding -a to both the default and -o5 almost doubled the compression speed, at a very small compression penalty. Graphs show these things into the right perspective! So:
-a -o5
-a
-a -o30
-a -b -o50
are the "presets" shown now (together with the default of course).
Anything with -7 or -z appears to compresses too slow, I'm trying to find one or two inbetweens that still give a decent compression improvement.

Latest MPEG-4 Audio Lossless Coding (ALS)

Reply #24 –
The reason -a gives such a boost is that the reference software is intentionally crippled, but -a (aside from what the help says it does) activates a binary module that uncripples one part. The optimized encoder I made does not have that problem.

Adding -a  would be good for all settings anyway (except for -o5, where it would normally be useless if it wasn't for the above).