IPB

Welcome Guest ( Log In | Register )

6 Pages V  < 1 2 3 4 5 > »   
Reply to this topicStart new topic
MPEG-4 Audio Lossless: final specifications, ...and first encoder is available!
kode54
post Dec 31 2005, 08:44
Post #51





Group: Admin
Posts: 4608
Joined: 15-December 02
Member No.: 4082



QUOTE (BoraBora @ Dec 30 2005, 07:23 AM)
QUOTE (Garf @ Dec 30 2005, 05:16 PM)
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? biggrin.gif 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. blink.gif
*

System specification?

QUOTE (keytotime @ Dec 30 2005, 10:26 AM)
yah that's what happen's to me to.
*

You too.

-v -7 -p -z3
CODE
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.
Go to the top of the page
+Quote Post
jimhaddon
post Dec 31 2005, 10:28
Post #52





Group: Members
Posts: 288
Joined: 22-July 03
Member No.: 7919



-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
Go to the top of the page
+Quote Post
jimhaddon
post Dec 31 2005, 11:19
Post #53





Group: Members
Posts: 288
Joined: 22-July 03
Member No.: 7919



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 wink.gif

This post has been edited by jimhaddon: Dec 31 2005, 11:25
Go to the top of the page
+Quote Post
BoraBora
post Dec 31 2005, 12:39
Post #54





Group: Members
Posts: 118
Joined: 17-November 04
From: Paris, France
Member No.: 18179



QUOTE (kode54 @ Dec 31 2005, 09:44 AM)
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.
Go to the top of the page
+Quote Post
SirGrey
post Dec 31 2005, 12:45
Post #55





Group: Members
Posts: 241
Joined: 8-February 04
Member No.: 11863



System specs:
WinXP SP1
C2600, Chaintech on Intel865PE, 512MB DDR 266
Go to the top of the page
+Quote Post
keytotime
post Dec 31 2005, 14:08
Post #56





Group: Members
Posts: 120
Joined: 22-December 05
Member No.: 26582



Xp Sp2
Celeron 2.7 ghz
1gb ram
Soyo 845Pe motherboard
Go to the top of the page
+Quote Post
jimhaddon
post Dec 31 2005, 15:46
Post #57





Group: Members
Posts: 288
Joined: 22-July 03
Member No.: 7919



Ok, i did a few more tests,
here are the results in Excel Format.

http://www.hydrogenaudio.org/forums/index....pe=post&id=2000
Go to the top of the page
+Quote Post
Garf
post Dec 31 2005, 15:55
Post #58


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



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).
Go to the top of the page
+Quote Post
jimhaddon
post Dec 31 2005, 19:34
Post #59





Group: Members
Posts: 288
Joined: 22-July 03
Member No.: 7919



Well, i just tried out the -7 -p -t2 switches, and they give me less compression than my switches did on the testing files
Go to the top of the page
+Quote Post
keytotime
post Dec 31 2005, 20:57
Post #60





Group: Members
Posts: 120
Joined: 22-December 05
Member No.: 26582



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

This post has been edited by keytotime: Dec 31 2005, 20:57
Go to the top of the page
+Quote Post
rjamorim
post Jan 2 2006, 02:41
Post #61


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



Interesting. Where is Heijden? I need to update my comparison cool.gif


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?

This post has been edited by rjamorim: Jan 2 2006, 02:58


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
keytotime
post Jan 2 2006, 04:00
Post #62





Group: Members
Posts: 120
Joined: 22-December 05
Member No.: 26582



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

This post has been edited by keytotime: Jan 2 2006, 04:01
Go to the top of the page
+Quote Post
Garf
post Jan 2 2006, 10:17
Post #63


Server Admin


Group: Admin
Posts: 4884
Joined: 24-September 01
Member No.: 13



QUOTE (rjamorim @ Jan 2 2006, 03:41 AM)
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?
*


3rd party solutions. It's not like we judge other formats based on reference software.
Go to the top of the page
+Quote Post
skamp
post Jan 4 2006, 02:36
Post #64





Group: Developer
Posts: 1430
Joined: 4-May 04
From: France
Member No.: 13875



  • 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)


This post has been edited by skamp: Jan 4 2006, 02:41


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
jcoalson
post Jan 4 2006, 05:47
Post #65


FLAC Developer


Group: Developer
Posts: 1526
Joined: 27-February 02
Member No.: 1408



QUOTE (skamp @ Jan 3 2006, 08:36 PM)
  • 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
Go to the top of the page
+Quote Post
rjamorim
post Jan 4 2006, 13:55
Post #66


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (skamp @ Jan 3 2006, 11:36 PM)
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)
*


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.


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
snookerdoodle
post Jan 4 2006, 18:53
Post #67





Group: Members
Posts: 120
Joined: 13-May 05
From: Albuquerque
Member No.: 22035



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
Go to the top of the page
+Quote Post
keytotime
post Jan 5 2006, 03:36
Post #68





Group: Members
Posts: 120
Joined: 22-December 05
Member No.: 26582



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 . headbang.gif And decoding is tied pretty close to encoding time.

This post has been edited by keytotime: Jan 5 2006, 03:40
Go to the top of the page
+Quote Post
Synaptic Line No...
post Jan 5 2006, 05:29
Post #69





Group: Members
Posts: 92
Joined: 19-May 05
Member No.: 22137



QUOTE
Multi-channel / multi-track support for up to 65536 channels (including 5.1 surround)


Only 65536? Darn, I wanted 228000000000000 channels!
Go to the top of the page
+Quote Post
Synaptic Line No...
post Jan 5 2006, 05:34
Post #70





Group: Members
Posts: 92
Joined: 19-May 05
Member No.: 22137



QUOTE (Busemann @ Dec 28 2005, 05:41 PM)
Pretty cool. The big question now is who will adopt it... Let's hope Apple Lossless was just a stop-gap solution smile.gif
*

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.
Go to the top of the page
+Quote Post
extesy
post Jan 5 2006, 11:44
Post #71





Group: Members
Posts: 10
Joined: 11-January 03
From: Russian Federation
Member No.: 4518



QUOTE (Synaptic Line Noise @ Jan 5 2006, 08:34 AM)
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 smile.gif
Go to the top of the page
+Quote Post
stephanV
post Jan 5 2006, 12:41
Post #72





Group: Members
Posts: 394
Joined: 6-May 04
Member No.: 13932



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."
Go to the top of the page
+Quote Post
skamp
post Jan 5 2006, 13:03
Post #73





Group: Developer
Posts: 1430
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (keytotime @ Jan 5 2006, 03:36 AM)
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 . headbang.gif And decoding is tied pretty close to encoding time.
*


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.

This post has been edited by skamp: Jan 5 2006, 13:49


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post
keytotime
post Jan 5 2006, 16:03
Post #74





Group: Members
Posts: 120
Joined: 22-December 05
Member No.: 26582



Try Mp4 -7 -P or Mp4 -7 -p -t2

This post has been edited by keytotime: Jan 5 2006, 16:03
Go to the top of the page
+Quote Post
skamp
post Jan 5 2006, 17:52
Post #75





Group: Developer
Posts: 1430
Joined: 4-May 04
From: France
Member No.: 13875



QUOTE (keytotime @ Jan 5 2006, 04:03 PM)
Try Mp4 -7 -P or Mp4 -7 -p -t2
*

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.

This post has been edited by skamp: Jan 5 2006, 17:55


--------------------
See my profile for measurements, tools and recommendations.
Go to the top of the page
+Quote Post

6 Pages V  < 1 2 3 4 5 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd August 2014 - 19:55