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



MPEG-4 Audio Lossless: final specifications

Reply #128
MPEG-4 SLS = AAC + correction layer. Can be scaled from Lossless to quality of the AAC stream. Backwards compatible. Can also work without AAC layer (not backwards compatible).

MPEG-4 ALS = 2 pure lossless codecs under one name. Works either similar to FLAC (normal settings) or Monkey Audio (-z settings)

AAC-HD = prolly just a trademark for one particular vendor's implementation of MPEG-4 SLS

MPEG-4 Audio Lossless: final specifications

Reply #129
Hi all,
I checked with the lastest source code (v.22). Why with some combined modes (e.g -t2 -z1 or -s2 -z1) the decoder cannot decode?
Is this legal setting?

Thanks!


MPEG-4 Audio Lossless: final specifications

Reply #131
I said -z3, not -z3 -p -t2 -b. These settings might not even work correctly.



ALS is really 2 totally different encoders:



1) foward prediction like FLAC: used by normal settings, and -7 and so, with extras like -p -t2 -b etc



2) backwards prediction like APE and WavPack: used by -z settings, won't combine with most of the other methods



You can use on or the other, but not both.

Thank Garf,
I'm just curious and a newbie about the ALS and s I checked source code of Encoder side, the backward adaptive predictor (z#) cannot combine with multichannel coding related option (i.e #t or #s)

Here is the my brief description:
EncodeFrame{
   if (RLSLMS){
      Encode...
   }
   if (MCC)
   {
      Encode...
   }
}
If we choose both -z# option and #t or #s option, so the MCC mode will overwrite the bitstream created by RLSLMS mode (and certainly these two bitstreams do not have equal length in byte).

But the Decoder will treat this bitstream as an RLS-LMS one, so that's the reason why the output of Decoder for two modes (-z#  -t#) and (-z# -s#) cannot correct, in the worse case it cannot even decode.