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 127446 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

MPEG-4 Audio Lossless: final specifications

Reply #50
Quote
Quote
Does it really stop or is it just insanely slow?

No, it stops and the prompt comes back. I have no error message, though I'm in verbose mode. Nothing. It starts then seems to change its mind and stops. Too much work, maybe?  I'll try again on a small sample.

Edit : well, same thing on a single short track, with or without -v. I don't understand. 
[a href="index.php?act=findpost&pid=353348"][{POST_SNAPBACK}][/a]

System specification?

Quote
yah that's what happen's to me to.
[a href="index.php?act=findpost&pid=353394"][{POST_SNAPBACK}][/a]

You too.

-v -7 -p -z3
Code: [Select]
PCM file: Hollister - Bismarck (full 24-96 original unmastered).wav
ALS file: Hollister - Bismarck (full 24-96 original unmastered).als

Encoding... 100% done

Audio format : int / 24 bit / 96000 Hz / 2 ch
Bit rate     : 4608.0 kbit/s
Playing time : 313.1 sec
PCM file size: 180318296 bytes
ALS file size: 96544854 bytes
Compr. ratio : 1.868 (53.54 %)
Average bps  : 12.850
Average rate : 2467.2 kbit/s

Processing took 2431.95 sec (0.1 x real-time)


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.

MPEG-4 Audio Lossless: final specifications

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

MPEG-4 Audio Lossless: final specifications

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

MPEG-4 Audio Lossless: final specifications

Reply #53
Quote
System specification?

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.

MPEG-4 Audio Lossless: final specifications

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

MPEG-4 Audio Lossless: final specifications

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


MPEG-4 Audio Lossless: final specifications

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

Quote
Well, seems to be a problem with the -z1/2/3 modes (backward prediction, similar to Monkey's Audio) which may not work together with other options (except -r#), since they are not intended to do so. Please don't expect the software to recognize all wrong parameter combinations.

Anyway, I would recommend to use -7 -p -t2 for maximum compression (-7 for near max), or  -7 -o100 (-p -t2) for a good  tradeoff in terms of decoding speed (encoding might still be a bit slow).

MPEG-4 Audio Lossless: final specifications

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

MPEG-4 Audio Lossless: final specifications

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

MPEG-4 Audio Lossless: final specifications

Reply #60
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?

MPEG-4 Audio Lossless: final specifications

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

MPEG-4 Audio Lossless: final specifications

Reply #62
Quote
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?
[a href="index.php?act=findpost&pid=353820"][{POST_SNAPBACK}][/a]


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

MPEG-4 Audio Lossless: final specifications

Reply #63
  • 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)

MPEG-4 Audio Lossless: final specifications

Reply #64
Quote
  • Seeking: I think it's set by the -r# switch: Random access (multiples of 0.1 sec), -1 = each frame, 0 = off (default)

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

MPEG-4 Audio Lossless: final specifications

Reply #65
Quote
Encoding speed: why is it reported as "slow"?? It's quite fast, on the contrary...


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

Quote
Seeking: I think it's set by the -r# switch: Random access (multiples of 0.1 sec), -1 = each frame, 0 = off (default)


Added it, thanks

Quote
Hybrid/lossy: no for now


Done

Quote
Piping: doesn't seem to work for now (but it might be a bug rather than just a lack of feature)[a href="index.php?act=findpost&pid=354378"][{POST_SNAPBACK}][/a]


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.

MPEG-4 Audio Lossless: final specifications

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

MPEG-4 Audio Lossless: final specifications

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

MPEG-4 Audio Lossless: final specifications

Reply #68
Quote
• Multi-channel / multi-track support for up to 65536 channels (including 5.1 surround)


Only 65536? Darn, I wanted 228000000000000 channels!

MPEG-4 Audio Lossless: final specifications

Reply #69
Quote
Pretty cool. The big question now is who will adopt it... Let's hope Apple Lossless was just a stop-gap solution
[a href="index.php?act=findpost&pid=352897"][{POST_SNAPBACK}][/a]

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.

MPEG-4 Audio Lossless: final specifications

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

MPEG-4 Audio Lossless: final specifications

Reply #71
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.
"We cannot win against obsession. They care, we don't. They win."

MPEG-4 Audio Lossless: final specifications

Reply #72
Quote
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.
[a href="index.php?act=findpost&pid=354653"][{POST_SNAPBACK}][/a]


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):
Quote
$ time { wavpack -h -o foo.wv 04\ -\ Souvenir.wav ; }
real   0m6.306s (36.5x)
user   0m5.915s
sys   0m0.214s

$ time { flac -o foo.flac --best 04\ -\ Souvenir.wav ; }
real   0m21.282s (10.8x)
user   0m20.173s
sys   0m0.249s

$ time { ofr --encode 04\ -\ Souvenir.wav --output foo.ofr ; }
real   0m15.488s (14.9x)
user   0m14.701s
sys   0m0.176s

$ time { mp4als -v 04\ -\ Souvenir.wav foo.als ; }
real   0m7.064s (32.6x)
user   0m6.686s
sys   0m0.166s


Decoding:
Quote
$ time { wvunpack -mq foo.wv -o bar.wav ; }
real   0m6.293s (36.5x)
user   0m5.795s
sys   0m0.197s

$ time { flac --decode --silent -o bar.wav foo.flac ; }
real   0m1.760s (130.7x)
user   0m1.611s
sys   0m0.107s

$ time { ofr --decode foo.ofr --output bar.wav ; }
real   0m11.498s (20.0x)
user   0m10.939s
sys   0m0.152s

$ time { mp4als -x foo.als bar.wav ; }
real   0m3.078s (74.7x)
user   0m2.652s
sys   0m0.303s


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.

MPEG-4 Audio Lossless: final specifications

Reply #73
Try Mp4 -7 -P or Mp4 -7 -p -t2

MPEG-4 Audio Lossless: final specifications

Reply #74
Quote
Try Mp4 -7 -P or Mp4 -7 -p -t2
[a href="index.php?act=findpost&pid=354798"][{POST_SNAPBACK}][/a]

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.