This moment was awaited for a long time, MPEG-4 lossless audio (ALS) specifications are now ready. Standardization were finalized recently and it was announced in Japan by the NTT company (source: here (http://www.acnnewswire.net/) and in french (http://www.pcinpact.com/actu/news/25673-Le-MPEG4-audio-sans-perte-standardise-au-Jap.htm?vc=1#vc))
MAIN FEATURES:
• Support for PCM resolutions of up to 32-bit at arbitrary sampling rate (including 16/44.1, 16/48, 24/48, 24/96, 24/192).
• Multi-channel / multi-track support for up to 65536 channels (including 5.1 surround).
• Support for 32-bit IEEE floating point audio data.
• Optional storage in MP4 file format (allows multiplex with video).
more info: here (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html)
download page: here (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html#downloads)
I'm currently running a comparison between the freely available MPEG-4 ALS encoder and other popular lossless tools.
My table:-
MPEG-4 {default}
-
flac 1.1.2 -8
-
WavPack 4.3 -fx5
-
WavPack 4.3 -x4
-
Monkey's Audio 3.99 "fast" /-c1000
-
Monkey's Audio 3.99 "normal" / -c2000
Files are my 150 reference
full tracks (=16 hours of music),
classical music only.
---------------------------------------------------------------------
MPEG-4 flac -8 WPack -fx5 WPack -x4 MAC 1000 MAC 2000
---------------------------------------------------------------------
| | | | |
614,28 | 633,87 | 628,72 | 618,27 | 616,05 | 603,20
---------------------------------------------------------------------
| | | | |
550,7 | 575,7 | 566,3 | 560,2 | 562,3 | 549,8
824,9 | 821,5 | 862,6 | 837,8 | 825,1 | 790,3
902,1 | 904,0 | 906,2 | 875,4 | 868,6 | 842,5
867,1 | 870,9 | 878,8 | 867,9 | 864,5 | 852,4
717,0 | 742,3 | 767,9 | 740,1 | 731,1 | 703,4
307,6 | 347,4 | 336,1 | 333,4 | 331,5 | 321,5
619,9 | 633,2 | 628,1 | 619,2 | 614,1 | 607,0
581,3 | 592,2 | 591,0 | 584,4 | 582,1 | 566,6
515,8 | 530,4 | 523,4 | 520,4 | 518,4 | 515,0
552,1 | 554,3 | 569,5 | 557,8 | 560,5 | 542,7
591,3 | 611,3 | 599,5 | 592,7 | 591,1 | 584,5
462,9 | 486,2 | 472,0 | 466,9 | 465,0 | 456,4
690,5 | 729,9 | 756,4 | 713,2 | 707,7 | 664,7
599,6 | 614,0 | 608,0 | 599,1 | 594,6 | 585,7
566,1 | 583,8 | 577,4 | 565,5 | 561,2 | 552,7
650,7 | 657,4 | 665,0 | 652,3 | 648,8 | 634,4
474,3 | 503,9 | 498,2 | 485,0 | 476,2 | 459,5
649,1 | 665,5 | 671,9 | 654,6 | 652,5 | 640,1
584,2 | 607,9 | 594,2 | 587,0 | 587,3 | 577,1
549,1 | 581,7 | 561,7 | 556,8 | 556,1 | 542,5
679,3 | 695,4 | 688,3 | 681,1 | 681,0 | 672,0
630,1 | 644,3 | 642,9 | 633,9 | 630,9 | 618,6
505,1 | 533,8 | 520,3 | 509,0 | 508,5 | 499,0
484,9 | 509,5 | 496,9 | 492,2 | 489,4 | 483,5
354,1 | 373,6 | 372,8 | 364,9 | 359,1 | 349,4
487,4 | 508,5 | 495,6 | 491,3 | 490,4 | 486,0
674,9 | 686,5 | 679,6 | 673,7 | 669,6 | 663,9
507,7 | 532,8 | 519,4 | 511,3 | 507,6 | 499,5
463,2 | 486,4 | 471,5 | 468,1 | 463,1 | 457,8
761,2 | 774,0 | 771,9 | 761,2 | 759,5 | 749,5
575,3 | 597,7 | 585,5 | 576,3 | 574,5 | 560,5
537,3 | 555,1 | 548,5 | 540,9 | 537,1 | 524,1
621,0 | 648,7 | 632,1 | 620,0 | 620,3 | 607,9
626,7 | 635,8 | 643,8 | 626,8 | 627,7 | 614,2
638,8 | 656,4 | 653,8 | 639,4 | 637,9 | 625,3
859,0 | 865,5 | 871,8 | 859,2 | 860,2 | 846,1
762,1 | 777,1 | 772,7 | 763,0 | 764,6 | 754,9
739,6 | 758,1 | 759,5 | 745,1 | 750,0 | 721,6
450,2 | 477,5 | 463,0 | 459,5 | 457,2 | 449,6
668,5 | 696,1 | 692,6 | 678,4 | 676,1 | 658,6
850,7 | 865,9 | 871,6 | 855,4 | 859,4 | 841,9
564,9 | 589,9 | 576,1 | 568,4 | 568,2 | 558,2
553,0 | 572,1 | 564,0 | 556,1 | 555,5 | 545,1
538,1 | 555,5 | 546,5 | 537,9 | 534,8 | 527,0
526,4 | 552,5 | 533,5 | 526,6 | 524,3 | 516,6
734,1 | 746,4 | 743,8 | 735,4 | 733,8 | 726,2
709,4 | 720,1 | 722,0 | 712,4 | 709,7 | 698,0
692,4 | 712,9 | 705,8 | 693,8 | 692,4 | 676,5
462,9 | 469,4 | 467,3 | 463,2 | 456,9 | 452,6
844,3 | 849,8 | 844,5 | 841,6 | 839,6 | 833,8
608,1 | 625,6 | 622,8 | 612,5 | 612,4 | 599,0
656,8 | 674,9 | 664,6 | 655,3 | 651,2 | 643,7
676,3 | 694,3 | 684,5 | 677,9 | 677,0 | 666,8
619,1 | 654,7 | 631,2 | 620,1 | 621,6 | 612,2
891,1 | 897,2 | 894,8 | 888,6 | 888,0 | 882,8
691,7 | 707,5 | 696,1 | 691,0 | 688,4 | 683,8
770,5 | 790,1 | 786,6 | 770,8 | 772,1 | 762,7
744,1 | 753,3 | 745,7 | 739,2 | 736,8 | 731,7
748,6 | 759,5 | 748,5 | 742,7 | 740,1 | 735,3
668,2 | 688,7 | 673,9 | 668,5 | 668,7 | 661,1
744,0 | 750,1 | 758,9 | 745,8 | 744,1 | 723,9
781,5 | 785,5 | 783,3 | 775,9 | 773,0 | 769,0
825,8 | 843,9 | 847,4 | 827,1 | 828,7 | 811,9
743,9 | 761,5 | 764,5 | 755,4 | 751,9 | 731,4
790,7 | 798,1 | 794,7 | 788,6 | 786,9 | 778,7
559,1 | 565,7 | 562,3 | 558,7 | 552,3 | 549,0
509,4 | 525,8 | 516,7 | 511,0 | 505,7 | 499,5
503,9 | 523,2 | 513,2 | 506,5 | 500,9 | 494,9
617,5 | 634,3 | 619,3 | 617,4 | 614,2 | 603,3
596,5 | 607,0 | 605,1 | 598,6 | 593,1 | 584,5
521,0 | 537,0 | 534,7 | 527,2 | 524,1 | 512,2
747,6 | 760,6 | 753,0 | 747,1 | 744,7 | 735,1
585,2 | 597,6 | 594,0 | 584,2 | 581,6 | 569,8
563,8 | 568,8 | 572,6 | 564,1 | 558,6 | 549,2
668,8 | 667,8 | 663,8 | 656,1 | 652,4 | 646,4
761,9 | 771,8 | 770,6 | 760,3 | 758,4 | 749,1
857,7 | 866,0 | 867,6 | 855,7 | 852,7 | 842,4
956,8 | 960,4 | 968,2 | 942,2 | 940,6 | 920,7
941,6 | 946,0 | 954,8 | 942,0 | 940,5 | 931,0
736,1 | 753,5 | 783,8 | 746,4 | 743,2 | 715,2
821,3 | 830,4 | 834,7 | 821,7 | 819,5 | 808,5
651,8 | 685,0 | 671,2 | 656,2 | 656,8 | 640,4
514,5 | 536,7 | 519,8 | 517,3 | 512,6 | 504,6
500,1 | 531,7 | 511,4 | 505,2 | 506,0 | 494,8
641,1 | 675,9 | 647,7 | 642,8 | 643,0 | 631,1
527,1 | 540,2 | 542,7 | 527,1 | 520,7 | 510,1
648,9 | 667,7 | 663,0 | 653,8 | 651,1 | 639,1
543,4 | 576,4 | 561,5 | 550,7 | 549,5 | 531,2
506,9 | 557,0 | 525,1 | 516,4 | 519,9 | 501,0
497,8 | 515,7 | 514,4 | 502,6 | 497,3 | 478,0
359,5 | 411,7 | 384,9 | 374,7 | 379,9 | 366,2
395,1 | 445,1 | 423,4 | 413,1 | 412,4 | 387,6
433,9 | 501,5 | 479,4 | 451,4 | 455,4 | 430,2
415,2 | 445,5 | 425,6 | 421,4 | 421,6 | 413,7
385,8 | 408,1 | 398,0 | 400,2 | 396,6 | 387,7
385,8 | 408,1 | 398,0 | 400,2 | 396,6 | 387,7
642,4 | 658,1 | 679,2 | 651,9 | 660,2 | 632,6
550,2 | 559,1 | 570,9 | 557,2 | 553,0 | 537,1
673,0 | 698,4 | 697,5 | 696,1 | 688,8 | 662,5
774,9 | 815,7 | 832,0 | 782,6 | 797,7 | 761,7
484,6 | 495,6 | 484,8 | 482,7 | 476,4 | 466,9
652,5 | 657,5 | 661,6 | 651,7 | 644,8 | 620,7
585,1 | 603,8 | 589,4 | 583,1 | 579,1 | 569,7
457,6 | 485,9 | 471,1 | 454,0 | 448,2 | 436,7
657,5 | 668,5 | 666,1 | 660,4 | 654,1 | 649,1
544,1 | 554,4 | 563,4 | 550,9 | 546,0 | 528,8
516,0 | 527,0 | 517,9 | 515,8 | 508,4 | 502,7
566,1 | 580,0 | 572,3 | 566,5 | 560,5 | 553,3
736,4 | 742,9 | 751,8 | 742,6 | 739,8 | 718,9
373,4 | 398,0 | 385,0 | 389,8 | 376,6 | 367,4
460,2 | 482,3 | 476,7 | 466,1 | 465,5 | 451,7
516,8 | 536,5 | 533,1 | 526,6 | 524,3 | 508,0
543,7 | 571,5 | 554,6 | 548,3 | 546,8 | 536,2
486,8 | 507,0 | 503,5 | 494,2 | 482,1 | 468,0
749,7 | 758,5 | 759,3 | 751,3 | 743,9 | 727,1
596,6 | 613,3 | 607,4 | 604,7 | 593,9 | 582,1
684,5 | 698,1 | 690,9 | 683,3 | 682,0 | 674,8
454,7 | 484,9 | 473,4 | 468,0 | 462,6 | 450,2
349,2 | 384,9 | 379,4 | 368,5 | 369,4 | 353,5
435,4 | 487,0 | 470,1 | 455,6 | 459,7 | 436,4
632,4 | 658,7 | 647,1 | 636,6 | 635,4 | 625,3
630,2 | 659,4 | 640,2 | 632,9 | 631,8 | 620,7
255,3 | 276,4 | 269,8 | 273,0 | 262,8 | 259,6
825,0 | 836,8 | 836,3 | 823,0 | 822,0 | 809,9
597,3 | 618,9 | 605,6 | 599,8 | 603,1 | 595,4
741,5 | 759,3 | 750,3 | 741,6 | 740,4 | 733,5
639,9 | 663,7 | 650,9 | 639,6 | 639,4 | 627,9
437,3 | 453,0 | 446,2 | 442,4 | 439,1 | 434,5
687,1 | 698,7 | 700,8 | 687,0 | 684,6 | 672,4
705,2 | 716,0 | 724,5 | 708,8 | 703,2 | 692,1
542,3 | 567,9 | 554,9 | 546,3 | 542,8 | 530,3
630,3 | 669,0 | 655,9 | 639,2 | 641,2 | 620,2
687,8 | 733,6 | 722,8 | 694,6 | 700,9 | 678,3
647,9 | 686,2 | 663,6 | 652,3 | 654,2 | 643,1
592,4 | 652,6 | 626,1 | 606,5 | 614,9 | 586,5
579,8 | 615,6 | 595,3 | 582,5 | 577,7 | 564,9
450,3 | 474,1 | 474,7 | 459,1 | 463,4 | 444,6
630,3 | 655,2 | 647,3 | 634,5 | 635,0 | 623,8
576,8 | 585,0 | 584,3 | 574,9 | 570,8 | 559,3
642,5 | 657,0 | 659,4 | 644,4 | 646,5 | 631,8
756,5 | 770,6 | 772,3 | 759,3 | 762,8 | 749,6
570,5 | 585,0 | 580,1 | 573,5 | 566,4 | 552,8
567,4 | 589,6 | 574,6 | 572,0 | 566,9 | 557,0
847,2 | 850,6 | 852,6 | 846,4 | 843,4 | 833,6
579,6 | 582,6 | 598,7 | 585,2 | 581,2 | 560,1
579,8 | 589,8 | 592,6 | 580,1 | 578,1 | 567,6
708,1 | 722,0 | 715,5 | 706,3 | 704,2 | 695,6
526,1 | 551,5 | 546,9 | 533,8 | 530,4 | 514,0
701,0 | 727,1 | 732,1 | 713,0 | 708,6 | 688,9
608,3 | 637,7 | 624,7 | 612,0 | 612,6 | 595,7
---------------------------------------------------------------------
| | | | |
614,28 | 633,87 | 628,72 | 618,27 | 616,05 | 603,20
---------------------------------------------------------------------
MPEG-4 flac -8 WPack-fx5 WPack -x4 MAC 1000 MAC 2000
---------------------------------------------------------------------
The comparison is meaningless without encoding and decoding speed. But I didn't find any decoder for measuring speed, and I'm running the encoding task on a laptop which is handicaped by a slow HDD. The comparison is just "informative".
EDIT: Monkey's audio bitrate were first wrong; they were edited one hour later. Sorry...
Usage (for interested people):
mp4alsRM16 - MPEG-4 Audio Lossless Coding (ALS), Reference Model Codec
Version 16 for Win32
(c) 2003-2005 Tilman Liebchen, Technical University of Berlin
E-mail: liebchen@nue.tu-berlin.de
Portions by Yuriy A. Reznik, RealNetworks, Inc.
E-mail: yreznik@real.com
Portions by Koichi Sugiura, NTT Advanced Technology corporation
E-mail: ksugiura@mitaka.ntt-at.co.jp
Portions by Takehiro Moriya, Noboru Harada and Yutaka Kamamoto, NTT
E-mail: t.moriya@ieee.org, {n-harada,kamamoto}@theory.brl.ntt.co.jp
Usage: mp4alsRM16 [options] infile [outfile]
In compression mode, infile must be a PCM file (wav, aif, or raw format)
or a 32-bit floating point file (normalized, wav format type 3).
Mono, stereo, and multichannel files with up to 65536 channels and up to
32-bit resolution are supported at any sampling frequency.
In decompression mode (-x), infile is the compressed file (.als).
If outfile is not specified, the name of the output file will be generated
by replacing the extension of the input file (wav <-> als).
If outfile is '-', the output will be written to stdout. If infile is '-',
the input will be read from stdin, and outfile has to be specified.
General Options:
-c : Check accuracy by decoding the whole file after encoding.
-d : Delete input file after completion.
-h : Help (this message)
-v : Verbose mode (file info, processing time)
-x : Extract (all options except -v are ignored)
Encoding Options:
-7 : Set parameters for optimum compression (except LTP, MCC, RLSLMS)
-a : Adaptive prediction order
-b : Use BGMC codes for prediction residual (default: use Rice codes)
-e : Exclude CRC calculation
-f#: ACF/MLZ mode: # = 0-7, -f6/-f7 requires ACF gain value
-g#: Block switching level: 0 = off (default), 5 = maximum
-i : Independent stereo coding (turn off joint stereo coding)
-l : Check for empty LSBs (e.g. 20-bit files)
-m#: Rearrange channel configuration (example: -m1,2,4,5,3)
-n#: Frame length: 0 = auto (default), max = 65536
-o#: Prediction order (default = 10), max = 1023
-p : Use long-term prediction
-r#: Random access (multiples of 0.1 sec), -1 = each frame, 0 = off (default)
-s#: Multi-channel correlation (#=1-65536, jointly code every # channels)
# must be a divisor of number of channels, otherwise -s is ignored
-t#: Two methods mode (Joint Stereo and Multi-channel correlation)
# must be a divisor of number of channels
-u#: Random access info location, 0 = frames (default), 1 = header, 2 = none
-z#: RLSLMS mode (default = 0: no RLSLMS mode, 1-quick, 2-medium 3-best )
Audio file support:
-R : Raw audio file (use -C, -W, -F and -M to specifiy format)
-S#: Sample type: 0 = integer (default), 1 = float
-C#: Number of Channels (default = 2)
-W#: Word length in bits per sample (default = 16)
-F#: Sampling frequency in Hz (default = 44100)
-M : 'MSByte first' byte order (otherwise 'LSByte first')
-H#: Header size in bytes (default = 0)
-T#: Trailer size in bytes (default = 0)
-I : Show info only, no (de)compression (add -x for compressed files)
Examples:
mp4alsRM16 -v sound.wav
mp4alsRM16 -n1024 -i -o20 sound.wav
mp4alsRM16 - sound.als < sound.wav
mp4alsRM16 -x sound.als
mp4alsRM16 -x sound.als - > sound.wav
mp4alsRM16 -I -x sound.als
with
foobar2000 (encoding only at the moment):
• extension: als
• parameters: -v %s %d
I'm currently running a comparison between the freely available MPEG-4 ALS encoder and other popular lossless tools.
My preliminary table:
- WavPack 4.3 -fx5
- MPEG-4 {default}
(other formats/setting are coming)
Files are my 150 reference full tracks (=16 hours of music), classical music only.
WavPack MPEG-4
A01... 566,3 550,7 -2,8 %
A02... 862,6 824,9 -4,4 %
A03... 906,2 902,1 -0,5 %
A04... 878,8 867,1 -1,3 %
A05... 767,9 717,0 -6,6 %
E01... 336,1 307,6 -8,5 %
E02... 628,1 619,9 -1,3 %
E03... 591,0 581,3 -1,7 %
E04... 523,4 515,8 -1,5 %
E05... 569,5 552,1 -3,1 %
E06... 599,5 591,3 -1,4 %
E07... 472,0 462,9 -1,9 %
E08... 756,4 690,5 -8,7 %
E09... 608,0 599,6 -1,4 %
E10... 577,4 566,1 -2,0 %
E11... 665,0 650,7 -2,2 %
E12... 498,2 474,3 -4,8 %
E13... 671,9 649,1 -3,4 %
E14... 594,2 584,2 -1,7 %
E15... 561,7 549,1 -2,3 %
E16... 688,3 679,3 -1,3 %
E17... 642,9 630,1 -2,0 %
E18... 520,3 505,1 -2,9 %
E19... 496,9 484,9 -2,4 %
E20... 372,8 354,1 -5,0 %
E21... 495,6 487,4 -1,7 %
E22... 679,6 674,9 -0,7 %
E23... 519,4 507,7 -2,3 %
E24... 471,5 463,2 -1,8 %
E25... 771,9 761,2 -1,4 %
E26... 585,5 575,3 -1,8 %
E27... 548,5 537,3 -2,0 %
E28... 632,1 621,0 -1,7 %
E29... 643,8 626,7 -2,6 %
E30... 653,8 638,8 -2,3 %
E31... 871,8 859,0 -1,5 %
E32... 772,7 762,1 -1,4 %
E33... 759,5 739,6 -2,6 %
E34... 463,0 450,2 -2,8 %
E35... 692,6 668,5 -3,5 %
E36... 871,6 850,7 -2,4 %
E37... 576,1 564,9 -2,0 %
E38... 564,0 553,0 -1,9 %
E39... 546,5 538,1 -1,5 %
E40... 533,5 526,4 -1,3 %
E41... 743,8 734,1 -1,3 %
E42... 722,0 709,4 -1,7 %
E43... 705,8 692,4 -1,9 %
E44... 467,3 462,9 -0,9 %
E45... 844,5 844,3 0,0 %
E46... 622,8 608,1 -2,4 %
E47... 664,6 656,8 -1,2 %
E48... 684,5 676,3 -1,2 %
E49... 631,2 619,1 -1,9 %
E50... 894,8 891,1 -0,4 %
E51... 696,1 691,7 -0,6 %
E52... 786,6 770,5 -2,1 %
E53... 745,7 744,1 -0,2 %
E54... 748,5 748,6 0,0 %
E55... 673,9 668,2 -0,8 %
E56... 758,9 744,0 -2,0 %
E57... 783,3 781,5 -0,2 %
E58... 847,4 825,8 -2,5 %
E59... 764,5 743,9 -2,7 %
E60... 794,7 790,7 -0,5 %
S01... 562,3 559,1 -0,6 %
S02... 516,7 509,4 -1,4 %
S03... 513,2 503,9 -1,8 %
S04... 619,3 617,5 -0,3 %
S05... 605,1 596,5 -1,4 %
S06... 534,7 521,0 -2,6 %
S07... 753,0 747,6 -0,7 %
S08... 594,0 585,2 -1,5 %
S09... 572,6 563,8 -1,5 %
S10... 663,8 668,8 0,8 %
S11... 770,6 761,9 -1,1 %
S12... 867,6 857,7 -1,1 %
S13... 968,2 956,8 -1,2 %
S14... 954,8 941,6 -1,4 %
S15... 783,8 736,1 -6,1 %
S16... 834,7 821,3 -1,6 %
S17... 671,2 651,8 -2,9 %
S18... 519,8 514,5 -1,0 %
S19... 511,4 500,1 -2,2 %
S20... 647,7 641,1 -1,0 %
S21... 542,7 527,1 -2,9 %
S22... 663,0 648,9 -2,1 %
S23... 561,5 543,4 -3,2 %
S24... 525,1 506,9 -3,5 %
S25... 514,4 497,8 -3,2 %
S26... 384,9 359,5 -6,6 %
S27... 423,4 395,1 -6,7 %
S28... 479,4 433,9 -9,5 %
S29... 425,6 415,2 -2,4 %
S30... 398,0 385,8 -3,1 %
S31... 398,0 385,8 -3,1 %
S32... 679,2 642,4 -5,4 %
S33... 570,9 550,2 -3,6 %
S34... 697,5 673,0 -3,5 %
S35... 832,0 774,9 -6,9 %
S36... 484,8 484,6 0,0 %
S37... 661,6 652,5 -1,4 %
S38... 589,4 585,1 -0,7 %
S39... 471,1 457,6 -2,9 %
S40... 666,1 657,5 -1,3 %
S41... 563,4 544,1 -3,4 %
S42... 517,9 516,0 -0,4 %
S43... 572,3 566,1 -1,1 %
S44... 751,8 736,4 -2,1 %
S45... 385,0 373,4 -3,0 %
S46... 476,7 460,2 -3,5 %
S47... 533,1 516,8 -3,1 %
S48... 554,6 543,7 -2,0 %
S49... 503,5 486,8 -3,3 %
S50... 759,3 749,7 -1,3 %
S51... 607,4 596,6 -1,8 %
S52... 690,9 684,5 -0,9 %
S53... 473,4 454,7 -4,0 %
S54... 379,4 349,2 -8,0 %
S55... 470,1 435,4 -7,4 %
V01... 647,1 632,4 -2,3 %
V02... 640,2 630,2 -1,6 %
V03... 269,8 255,3 -5,3 %
V04... 836,3 825,0 -1,4 %
V05... 605,6 597,3 -1,4 %
V06... 750,3 741,5 -1,2 %
V07... 650,9 639,9 -1,7 %
V08... 446,2 437,3 -2,0 %
V09... 700,8 687,1 -2,0 %
V10... 724,5 705,2 -2,7 %
V11... 554,9 542,3 -2,3 %
V12... 655,9 630,3 -3,9 %
V13... 722,8 687,8 -4,8 %
V14... 663,6 647,9 -2,4 %
V15... 626,1 592,4 -5,4 %
V16... 595,3 579,8 -2,6 %
V17... 474,7 450,3 -5,1 %
V18... 647,3 630,3 -2,6 %
V19... 584,3 576,8 -1,3 %
V20... 659,4 642,5 -2,6 %
V21... 772,3 756,5 -2,1 %
V22... 580,1 570,5 -1,7 %
V23... 574,6 567,4 -1,3 %
V24... 852,6 847,2 -0,6 %
V25... 598,7 579,6 -3,2 %
V26... 592,6 579,8 -2,2 %
V27... 715,5 708,1 -1,0 %
V28... 546,9 526,1 -3,8 %
V29... 732,1 701,0 -4,2 %
V30... 624,7 608,3 -2,6 %
________________________________
628,72 614,28 -2,3 %
The comparison is meaningless with encoding and decoding speed. But I didn't find any decoder for measuring speed, and I'm running the encoding task on a laptop which is handicaped by a slow HDD. The comparison is just "informative".
[a href=\"index.php?act=findpost&pid=352885\"][{POST_SNAPBACK}][/a]
This is just fantastic news!
*cheers*
Scince this MPEG-4 lossless audio is standardized, does this mean that hardware support will be at least more abundant than the currently available players with any kind of lossless support?
Scince this MPEG-4 lossless audio is standardized, does this mean that hardware support will be at least more abundant than the currently available players with any kind of lossless support?
[a href="index.php?act=findpost&pid=352894"][{POST_SNAPBACK}][/a]
Only if manufacturers are interested to implement lossless. And MPEG-4 ALS have to fight against other formats like:
- Apple Lossless
- WMA Lossless
- Sony's lossless
- FLAC
N.B. Monkey's normal has been add in the table.
Pretty cool. The big question now is who will adopt it... Let's hope Apple Lossless was just a stop-gap solution
Scince this MPEG-4 lossless audio is standardized, does this mean that hardware support will be at least more abundant than the currently available players with any kind of lossless support?
[a href="index.php?act=findpost&pid=352894"][{POST_SNAPBACK}][/a]
Only if manufacturers are interested to implement lossless. And MPEG-4 ALS have to fight against other formats like:
- Apple Lossless
- WMA Lossless
- Sony's lossless
- FLAC
N.B. Monkey's normal has been add in the table.
[a href="index.php?act=findpost&pid=352896"][{POST_SNAPBACK}][/a]
Right, I don't see those companies abandoning their proprietary formats.
Yes, it uses BSAC (Bit-slice arithmetic coding). Correct me if I am wrong but isn't ALS hybrid codec that would be the purpose of BSAC? When I read the Research Paper on it that was the impression I got or am I missing something here? Is that something different.
Right, I don't see those companies abandoning their proprietary formats.
If there is money to be made from it they sure as hell won't at the cost of patenting some other general coding technique used in data compression.
I tried a few encodings just to see the kind of compression & speed to expect. I put the encoder on verbose to get the speed and bitrate. I put comparison bitrates next to the "Average Rate" row, the comparisons are FLAC 1.1.2 at compression level -8.
My computer is fairly modern, it consists of:
Athlon 64 3500+ (2200MHz)
2GB PC3200 RAM (128 Bit Dual Channel)
Encoding From: 36GB SATA HDD
Encoding To : 250GB SATA HDD
------------------------------------------------------
mp4als -v (default)
------------------------------------------------------
PCM file: 01.dixie chicks - i can love you better.wav
ALS file: 01.dixie chicks - i can love you better.als
Encoding... 100% done
Audio format : int / 16 bit / 44100 Hz / 2 ch
Bit rate : 1411.2 kbit/s
Playing time : 233.9 sec
PCM file size: 41254124 bytes
ALS file size: 29225703 bytes
Compr. ratio : 1.412 (70.84 %)
Average bps : 11.335
Average rate : 999.7 kbit/s [ FLAC -8 1007 kbit/s ]
Processing took 6.77 sec (34.6 x real-time)
------------------------------------------------------
mp4als -v (default)
------------------------------------------------------
PCM file: 01.dntel - (this is) the dream of evan and chan.wav
ALS file: 01.dntel - (this is) the dream of evan and chan.als
Encoding... 100% done
Audio format : int / 16 bit / 44100 Hz / 2 ch
Bit rate : 1411.2 kbit/s
Playing time : 344.9 sec
PCM file size: 60846284 bytes
ALS file size: 41706162 bytes
Compr. ratio : 1.459 (68.54 %)
Average bps : 10.967
Average rate : 967.3 kbit/s [ FLAC -8 939 kbit/s ]
Processing took 9.88 sec (34.9 x real-time)
------------------------------------------------------
mp4als -v (default)
------------------------------------------------------
PCM file: 01.enya - only time.wav
ALS file: 01.enya - only time.als
Encoding... 100% done
Audio format : int / 16 bit / 44100 Hz / 2 ch
Bit rate : 1411.2 kbit/s
Playing time : 218.0 sec
PCM file size: 38462300 bytes
ALS file size: 23376405 bytes
Compr. ratio : 1.645 (60.78 %)
Average bps : 9.724
Average rate : 857.7 kbit/s [ FLAC -8 874 kbit/s ]
Processing took 6.31 sec (34.5 x real-time)
------------------------------------------------------
mp4als -v (default)
------------------------------------------------------
PCM file: 01.eric clapton - tears in heaven.wav
ALS file: 01.eric clapton - tears in heaven.als
Encoding... 100% done
Audio format : int / 16 bit / 44100 Hz / 2 ch
Bit rate : 1411.2 kbit/s
Playing time : 273.1 sec
PCM file size: 48180764 bytes
ALS file size: 26903509 bytes
Compr. ratio : 1.791 (55.84 %)
Average bps : 8.934
Average rate : 788.0 kbit/s [ FLAC -8 805 kbit/s ]
Processing took 7.91 sec (34.5 x real-time)
------------------------------------------------------
mp4als -v (default)
------------------------------------------------------
PCM file: 01.sigur r≤s - sΘ lest.wav
ALS file: 01.sigur r≤s - sΘ lest.als
Encoding... 100% done
Audio format : int / 16 bit / 44100 Hz / 2 ch
Bit rate : 1411.2 kbit/s
Playing time : 520.5 sec
PCM file size: 91810364 bytes
ALS file size: 44832450 bytes
Compr. ratio : 2.048 (48.83 %)
Average bps : 7.813
Average rate : 689.1 kbit/s [ FLAC -8 703 kbit/s ]
Processing took 15.13 sec (34.4 x real-time)
I wanted to see how fast the encoder was with the "-7" switch, and at this point, it is
very slow. Obviously this is an initial release and the specification is new, but man that's slow.
------------------------------------------------------
mp4als -v -7 (Set parameters for optimum compression)
------------------------------------------------------
PCM file: 01.enya - only time.wav
ALS file: 01.enya - only time.als
Encoding... 100% done
Audio format : int / 16 bit / 44100 Hz / 2 ch
Bit rate : 1411.2 kbit/s
Playing time : 218.0 sec
PCM file size: 38462300 bytes
ALS file size: 22675979 bytes
Compr. ratio : 1.696 (58.96 %)
Average bps : 9.433
Average rate : 832.0 kbit/s
Processing took 186.70 sec (1.2 x real-time)
Interesting to see that the default settings are giving better compression than FLAC's highest setting. Seems the compression levels will be closer to Wavpack than FLAC. Very cool news, thanks for the info Guruboolez.
Before the bed:
-
WavPack 4.3 -fx5-
flac 1.1.2 -8-
Monkey's Audio 3.99 -normal-
MPEG-4 ALS 2005.12.28 {defaut}
The setting I used for WavPack and flac are those giving the best compressing ratio with no sacrifice on the decompressing speed. For MAC, I used he default setting, which offers IMO the best compromise between ratio (strong), encoding speed (fast) and decoding speed (decent).flac WavPack MPEG-4 Monkey's
575,7 566,3 550,7 549,8
821,5 862,6 824,9 790,3
904,0 906,2 902,1 842,5
870,9 878,8 867,1 852,4
742,3 767,9 717,0 703,4
347,4 336,1 307,6 321,5
633,2 628,1 619,9 607,0
592,2 591,0 581,3 566,6
530,4 523,4 515,8 515,0
554,3 569,5 552,1 542,7
611,3 599,5 591,3 584,5
486,2 472,0 462,9 456,4
729,9 756,4 690,5 664,7
614,0 608,0 599,6 585,7
583,8 577,4 566,1 552,7
657,4 665,0 650,7 634,4
503,9 498,2 474,3 459,5
665,5 671,9 649,1 640,1
607,9 594,2 584,2 577,1
581,7 561,7 549,1 542,5
695,4 688,3 679,3 672,0
644,3 642,9 630,1 618,6
533,8 520,3 505,1 499,0
509,5 496,9 484,9 483,5
373,6 372,8 354,1 349,4
508,5 495,6 487,4 486,0
686,5 679,6 674,9 663,9
532,8 519,4 507,7 499,5
486,4 471,5 463,2 457,8
774,0 771,9 761,2 749,5
597,7 585,5 575,3 560,5
555,1 548,5 537,3 524,1
648,7 632,1 621,0 607,9
635,8 643,8 626,7 614,2
656,4 653,8 638,8 625,3
865,5 871,8 859,0 846,1
777,1 772,7 762,1 754,9
758,1 759,5 739,6 721,6
477,5 463,0 450,2 449,6
696,1 692,6 668,5 658,6
865,9 871,6 850,7 841,9
589,9 576,1 564,9 558,2
572,1 564,0 553,0 545,1
555,5 546,5 538,1 527,0
552,5 533,5 526,4 516,6
746,4 743,8 734,1 726,2
720,1 722,0 709,4 698,0
712,9 705,8 692,4 676,5
469,4 467,3 462,9 452,6
849,8 844,5 844,3 833,8
625,6 622,8 608,1 599,0
674,9 664,6 656,8 643,7
694,3 684,5 676,3 666,8
654,7 631,2 619,1 612,2
897,2 894,8 891,1 882,8
707,5 696,1 691,7 683,8
790,1 786,6 770,5 762,7
753,3 745,7 744,1 731,7
759,5 748,5 748,6 735,3
688,7 673,9 668,2 661,1
750,1 758,9 744,0 723,9
785,5 783,3 781,5 769,0
843,9 847,4 825,8 811,9
761,5 764,5 743,9 731,4
798,1 794,7 790,7 778,7
565,7 562,3 559,1 549,0
525,8 516,7 509,4 499,5
523,2 513,2 503,9 494,9
634,3 619,3 617,5 603,3
607,0 605,1 596,5 584,5
537,0 534,7 521,0 512,2
760,6 753,0 747,6 735,1
597,6 594,0 585,2 569,8
568,8 572,6 563,8 549,2
667,8 663,8 668,8 646,4
771,8 770,6 761,9 749,1
866,0 867,6 857,7 842,4
960,4 968,2 956,8 920,7
946,0 954,8 941,6 931,0
753,5 783,8 736,1 715,2
830,4 834,7 821,3 808,5
685,0 671,2 651,8 640,4
536,7 519,8 514,5 504,6
531,7 511,4 500,1 494,8
675,9 647,7 641,1 631,1
540,2 542,7 527,1 510,1
667,7 663,0 648,9 639,1
576,4 561,5 543,4 531,2
557,0 525,1 506,9 501,0
515,7 514,4 497,8 478,0
411,7 384,9 359,5 366,2
445,1 423,4 395,1 387,6
501,5 479,4 433,9 430,2
445,5 425,6 415,2 413,7
408,1 398,0 385,8 387,7
408,1 398,0 385,8 387,7
658,1 679,2 642,4 632,6
559,1 570,9 550,2 537,1
698,4 697,5 673,0 662,5
815,7 832,0 774,9 761,7
495,6 484,8 484,6 466,9
657,5 661,6 652,5 620,7
603,8 589,4 585,1 569,7
485,9 471,1 457,6 436,7
668,5 666,1 657,5 649,1
554,4 563,4 544,1 528,8
527,0 517,9 516,0 502,7
580,0 572,3 566,1 553,3
742,9 751,8 736,4 718,9
398,0 385,0 373,4 367,4
482,3 476,7 460,2 451,7
536,5 533,1 516,8 508,0
571,5 554,6 543,7 536,2
507,0 503,5 486,8 468,0
758,5 759,3 749,7 727,1
613,3 607,4 596,6 582,1
698,1 690,9 684,5 674,8
484,9 473,4 454,7 450,2
384,9 379,4 349,2 353,5
487,0 470,1 435,4 436,4
658,7 647,1 632,4 625,3
659,4 640,2 630,2 620,7
276,4 269,8 255,3 259,6
836,8 836,3 825,0 809,9
618,9 605,6 597,3 595,4
759,3 750,3 741,5 733,5
663,7 650,9 639,9 627,9
453,0 446,2 437,3 434,5
698,7 700,8 687,1 672,4
716,0 724,5 705,2 692,1
567,9 554,9 542,3 530,3
669,0 655,9 630,3 620,2
733,6 722,8 687,8 678,3
686,2 663,6 647,9 643,1
652,6 626,1 592,4 586,5
615,6 595,3 579,8 564,9
474,1 474,7 450,3 444,6
655,2 647,3 630,3 623,8
585,0 584,3 576,8 559,3
657,0 659,4 642,5 631,8
770,6 772,3 756,5 749,6
585,0 580,1 570,5 552,8
589,6 574,6 567,4 557,0
850,6 852,6 847,2 833,6
582,6 598,7 579,6 560,1
589,8 592,6 579,8 567,6
722,0 715,5 708,1 695,6
551,5 546,9 526,1 514,0
727,1 732,1 701,0 688,9
637,7 624,7 608,3 595,7
____________________________________
633,87 628,72 614,28 603,20
=> MPEG-4 ALS has a better ratio than the current "very fast" and modern lossless encoders (
flac and
WavPack fast)
=> MPEG-4 ALS has a worse ratio than
Monkey's -normal / -c2000
(results for classical music, but from my experience the difference between formats are extrapolable to other musical genres - with a higher bitrate...)As a consequence, I expect from this first implementation and for the encoding side
to perform as good as Monkey's -fast/-c1000 (fast encoding/average decoding)
or WavPack -x4 (very slow encoding/really fast decoding).
The question now is: how fast/complex is the decoding side? As fast as Wavpack/flac? Slower than Monkey's?
I did a small test on
Where Is the Line by Björk, from the album
Medúlla, ripped from a DVD-Audio (losslessly, search the forums). The audio is 24bit, 96kHz, 6 channels (5.1).
03 - Where Is the Line.wav: 462.827 MiB
mp4 (default): 185.525 MiB 0m 58.920s
mp4 -7 (best): 172.122 MiB 38m 21.697s
wavpack -hm: 241.043 MiB 1m 2.869s
wavpack -hmx1: 240.871 MiB 2m 50.220s
wavpack -hmx2: 215.992 MiB 5m 48.687s
wavpack -hmx3: 179.891 MiB 30m 50.188s
wavpack -hmx6: to be done
flac --best: 238.116 MiB 3m 22.062s
I have to say, the results are very, VERY impressive. I'm currently encoding the whole album to wavpack -hmx6 for my own use, so I'll do more testing later. But man, I can't wait for that codec to be supported by Free Software (I use linux most of the time).
Edit: added the filesize of the reference .wav file.
Does anybody know what patents are being used in MPEG-4 ALS and what the licensing terms are?
Just out of curiosity, has anyone done bit comparisons to prove total lossless-ness?
Wasn't LPAC the codec chosen a while ago for MPEG4 because of the lack of applicants?
Just out of curiosity, has anyone done bit comparisons to prove total lossless-ness?
[a href="index.php?act=findpost&pid=352991"][{POST_SNAPBACK}][/a]
I just checked it out on a couple of files. The files I tested, coded then decoded all were bit accurate. I used the bit comparator in foobar2000. I checked the filesizes in windows and they were exact too.
Try this:
-b : Use BGMC codes for prediction residual (default: use Rice codes)
Edit: hmm, I guess -7 already does that. What's the effect of -p ? Try -z3, too.
-7 -p -z3 should give best compression ratio
Thanks Guru for the comparisson
Yes, it uses BSAC (Bit-slice arithmetic coding). Correct me if I am wrong but isn't ALS hybrid codec that would be the purpose of BSAC? When I read the Research Paper on it that was the impression I got or am I missing something here? Is that something different.
[a href="index.php?act=findpost&pid=352904"][{POST_SNAPBACK}][/a]
You are confusing it with SLS perhaps?
you are confusing it with SLS perhaps?
SLS that's what I am thinking of
Ok, here is an encoding/decoding speed test. Album used is The Joshua Tree from U2, athlon64 (1.8GHz) cpu and linux. I have used 32-bit executables as there isn't a 64-bit object file for the adaptive prediction algorithm in the mpeg4als.zip.
kbps encoding decoding
flac 1.1.2 770.0 53.9x 168.7x
flac 1.1.2 -8 767.2 7.1x 166.8x
wavpack 4.31 759.8 72.0x 77.6x
wavpack 4.31 -fx5 765.4 8.1x 101.8x
wavpack 4.31 -x4 748.6 3.5x 79.8x
mp4alsRM16 748.7 24.2x 69.2x
mp4alsRM16 -7 723.5 0.81x 6.65x
Edit: Added wavpack test.
The table is updated on the second post of this thread. Were just added:
- MAC 3.99 -fast
- WavPack 4.3 -x4
Summary:
• MPEG-4 default = 614,28 kbps
• flac -8 = 633,87
• WavPack -fx5 = 628,72
• WavPack -x4 = 618,27
• MAC -c1000 = 616,05
• MAC -c2000 = 603,20
=> MPEG-4 default has nearly the same compression ratio on this musical genre than WavPack -hx4 and Monkey's Audio -fast.
• Decoding speed (old Duron 800): x39 (WavPack) x20 (MAC)
• Encoding speed (old Duron 800): x1.1 (WavPack) x19 (MAC)
I can't evaluate speed on my laptop: results are varying too much from one encoding/decoding to another one.
I did a small test on Where Is the Line by Björk, from the album Medúlla, ripped from a DVD-Audio (losslessly, search the forums). The audio is 24bit, 96kHz, 6 channels (5.1).
03 - Where Is the Line.wav: 462.827 MiB
mp4 (default): 185.525 MiB 0m 58.920s
mp4 -7 (best): 172.122 MiB 38m 21.697s
wavpack -hm: 241.043 MiB 1m 2.869s
wavpack -hmx1: 240.871 MiB 2m 50.220s
wavpack -hmx2: 215.992 MiB 5m 48.687s
wavpack -hmx3: 179.891 MiB 30m 50.188s
wavpack -hmx6: to be done
flac --best: 238.116 MiB 3m 22.062s
I have to say, the results are very, VERY impressive. I'm currently encoding the whole album to wavpack -hmx6 for my own use, so I'll do more testing later. But man, I can't wait for that codec to be supported by Free Software (I use linux most of the time).
Edit: added the filesize of the reference .wav file.
[a href="index.php?act=findpost&pid=352946"][{POST_SNAPBACK}][/a]
Impressive! Now I'm really interested.
for the amount of muscles ALS is throwing at the problem the results are a bit disappointing.
Just my own little test:
AMD Sempron64 3400+
Corsair 1GB DDR XMS3200XL Platinum TwinX (2x512MB) CAS2
2 X Samsung SpinPoint P120 SATA Series SP2504C (from one to the other)
81.974.300 10 - War Pigs.wav
wavpack -hx4
created 10 - War Pigs.wv in 390.01 secs (lossless, 29.80%)
57.548.910 10 - War Pigs.wv
mp4alsRM16.exe -7
*Stop Watch 00:08:24.61
57.289.738 10 - War Pigs.als
for the amount of muscles ALS is throwing at the problem the results are a bit disappointing.
[a href="index.php?act=findpost&pid=353064"][{POST_SNAPBACK}][/a]
this is a
reference encoder - keep that in mind. It will not reflect perfomance once this has been adopted by the companies interested in this new exciting standard.
for the amount of muscles ALS is throwing at the problem the results are a bit disappointing.
[a href="index.php?act=findpost&pid=353064"][{POST_SNAPBACK}][/a]
this is a reference encoder - keep that in mind. It will not reflect perfomance once this has been adopted by the companies interested in this new exciting standard.
[a href="index.php?act=findpost&pid=353084"][{POST_SNAPBACK}][/a]
And given that, the results are already impressive, especially for DVD-Audio.
Does anybody know what patents are being used in MPEG-4 ALS and what the licensing terms are?
[a href="index.php?act=findpost&pid=352960"][{POST_SNAPBACK}][/a]
That won't be known for quite a while. The MPEGLA does a call for patents, and tries to get everyone who has one that applies to MPEG4 ALS to agree on a common licensing agreement.
this is a reference encoder - keep that in mind. It will not reflect perfomance once this has been adopted by the companies interested in this new exciting standard.
this is not a lossy framework as mp3 for example so i doubt that there will
be large improvements as the decoder has to be the same and tweaking
would break it. anyway lets see.
this is a reference encoder - keep that in mind. It will not reflect perfomance once this has been adopted by the companies interested in this new exciting standard.
this is not a lossy framework as mp3 for example so i doubt that there will
be large improvements as the decoder has to be the same and tweaking
would break it. anyway lets see.
[a href="index.php?act=findpost&pid=353095"][{POST_SNAPBACK}][/a]
In terms of compression ratio, I would agree that significant improvement is unlikely. But in terms of speed, I would expect massive improvements.
here (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html#downloads)
is it me or is the source code zip missing lpc_adapt.cpp?
here (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html#downloads)
is it me or is the source code zip missing lpc_adapt.cpp?
[a href="index.php?act=findpost&pid=353107"][{POST_SNAPBACK}][/a]
readme.txt is called like that for a reason
heh, yeah I already built a linux binary. the readme doesn't say why it's missing though.
I don't see why all the fuss about encoding speed, it's the decode that matters. on my machine, default ALS decodes about twice as slow as default FLAC. it will be nice to see Hans' table updated for the big picture.
Josh
heh, yeah I already built a linux binary. the readme doesn't say why it's missing though.
I don't see why all the fuss about encoding speed, it's the decode that matters. on my machine, default ALS decodes about twice as slow as default FLAC. it will be nice to see Hans' table updated for the big picture.
Josh
[a href="index.php?act=findpost&pid=353166"][{POST_SNAPBACK}][/a]
Yes, I agree: current speed is disappointing. Especially for higher than defaut compression level:
-z1 = decoding time = x0.9 on a laptop (AMD Athlon XP 2000+) and ratio is not impressive compared to extreme formats such as OptimFROG, LA or even MAC -c4000/5000 which are clearly less painful on the decoding side (and encoding too).
-7 = decoding time = x9 on the same computer. For such slow but acceptable (for PC) speed, ratios have nothing extraordinary.
For default setting, I was able to reach x60, whereas flac and WavPack -f could both reach x120.
Quick question, which app can play the als files?
A quick and dirty test. Timings are not accurate, I did a lot of work on my PC while encoding/decoding.
(http://perso.wanadoo.fr/borabora/mpeg4.gif)
PIV 3.0 Ghz.
How slow and how compact is -7 -p -z3 ?
Does it beat the most insane OptimFROG lines?
-7 -p -z3 does not work.
-7 -p works.
-z3 -p works.
OptimFrog --mode bestnew --seek slow 40,418,314 bytes
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
Mp4 -z3 -p 41,186,238 bytes Decoding 2971.78 Seconds
Wavpack -h 42,901,452 bytes
flac -8 44,255,687 bytes
wav 100,900,844 bytes
close but the frog still wins.
-7 -p -z3 does not work.
[a href="index.php?act=findpost&pid=353315"][{POST_SNAPBACK}][/a]
Sure it does!
C:\work>mp4alsrm16 -7 -p -z3 metal.wav
C:\work>mp4alsrm16 metal.wav metaldft.als
C:\work>dir *.als
Volume in drive C has no label.
Volume Serial Number is 284A-BB0F
Directory of C:\work
30/12/2005 15:35 32.952.320 metal.als
30/12/2005 15:37 34.826.981 metaldft.als
2 File(s) 67.779.301 bytes
0 Dir(s) 5.524.795.392 bytes free
-7 : Set parameters for optimum compression (except LTP, MCC, RLSLMS)
-z#: RLSLMS mode (default = 0: no RLSLMS mode, 1-quick, 2-medium 3-best )
-7 : Set parameters for optimum compression (except LTP, MCC, RLSLMS)
-z#: RLSLMS mode (default = 0: no RLSLMS mode, 1-quick, 2-medium 3-best )
[a href="index.php?act=findpost&pid=353329"][{POST_SNAPBACK}][/a]
What are you trying to say here?
That the program says that it cann't work. -7 can not work with RLSLMS mode and -z3 set's RLSLMS mode.
That the program says that it cann't work. -7 can not work with RLSLMS mode and -z3 set's RLSLMS mode.
[a href="index.php?act=findpost&pid=353332"][{POST_SNAPBACK}][/a]
You are wrong, it doesn't say it cannot work. -7 sets the parameters to the optimum, EXCEPT the ones for LTP, MCC and RLSLMS. (I guess because the effect on speed). But you can still manually set those to the optimum values.
I already showed you can, and BoraBora's result shows that they have effect.
*slap's himself with a trout*
Sorry.
-7 = decoding time = x9 on the same computer. [a href="index.php?act=findpost&pid=353169"][{POST_SNAPBACK}][/a]
Interesting, your decoding of a -7 file is faster than mine even though I have a faster cpu. I tried some other files and it looks like decoding speed is very variable. I made a graph showing the variability, decoded is whole album (507MB). However, decoding speed for a file encoded with default settings is pretty stable.
(http://img399.imageshack.us/img399/9929/alsspeed9fo.png)
How slow and how compact is -7 -p -z3 ?
Does it beat the most insane OptimFROG lines?
[a href="index.php?act=findpost&pid=353306"][{POST_SNAPBACK}][/a]
It may be. For some reason, I can't make work "-7 -p -z3". Encoding stops after a couple of seconds. Weird.
I tried "-s2" and "-s2 -p", though :
186661407 46,36% "-p -s2"
186886405 46,42% "-s2"
186900432 46,42% "-p"
187611042 46,60% default
It may be. For some reason, I can't make work "-7 -p -z3". Encoding stops after a couple of seconds. Weird.
[a href="index.php?act=findpost&pid=353346"][{POST_SNAPBACK}][/a]
Does it really stop or is it just insanely slow?
I would expect results from -7 -z3 to be better than all others you tried, if you can't get -7 -p -z3 to work.
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.
yah that's what happen's to me to.
For me:
-7 switch does not work with -z3 switch. Or wise versa
-z3 alone works.
If somebody isn't lazy enought to find, what switches -7 sets or resets, then he will be able to find the specific switch that doesn't work with -z3...
EDIT: BTW, for me encoding with -7 -z3 is ended imidiately, not after some seconds...
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?
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
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.
-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
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
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.
System specs:
WinXP SP1
C2600, Chaintech on Intel865PE, 512MB DDR 266
Xp Sp2
Celeron 2.7 ghz
1gb ram
Soyo 845Pe motherboard
Ok, i did a few more tests,
here are the results in Excel Format.
http://www.hydrogenaudio.org/forums/index....pe=post&id=2000 (http://www.hydrogenaudio.org/forums/index.php?act=Attach&type=post&id=2000)
I emailed the ALS people and it seems you guys were right and I was wrong:
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).
Well, i just tried out the -7 -p -t2 switches, and they give me less compression than my switches did on the testing files
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
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 (http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison#Comparison_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?
You can add for software support, none as of yet. Encoding/Decong Speed slow. Hybrid/lossy None.
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.
- 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)
- 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
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.
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
Hybrid/lossy: no for now
Done
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.
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
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.
• Multi-channel / multi-track support for up to 65536 channels (including 5.1 surround)
Only 65536? Darn, I wanted 228000000000000 channels!
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.
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
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.
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):
$ 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:
$ 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.
Try Mp4 -7 -P or Mp4 -7 -p -t2
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.
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.
[a href="index.php?act=findpost&pid=354756"][{POST_SNAPBACK}][/a]
You can look at it from another perspective - companies didn't have much of a choice than giving support for mp3.
Also the adoption of a loseless format would mean higher bandwith use. 4mb verus 30mb.
Also the adoption of a loseless format would mean higher bandwith use. 4mb verus 30mb.
Average connection speed today is much faster than it was at the time when MP3 was invented.
Average connection speed today is much faster than it was at the time when MP3 was invented.
[a href="index.php?act=findpost&pid=355027"][{POST_SNAPBACK}][/a]
But think in the servers point of view. I don't want to have an 10 times bigger bill if the lossy formats sound just fine. Lossy formats won't disapear soon. Images are still encoded in jpg format for example.
Apart from a smaller filesize, what's so exciting about ANOTHER lossless format? Are there really not enough different audio-formats out there, not just to mention all the different lossless formats????
Personally I've given vorbis a try, but I forced myself back to MP3 for compatibility reasons.
Apart from a smaller filesize, what's so exciting about ANOTHER lossless format? Are there really not enough different audio-formats out there, not just to mention all the different lossless formats????
Personally I've given vorbis a try, but I forced myself back to MP3 for compatibility reasons.
[a href="index.php?act=findpost&pid=356299"][{POST_SNAPBACK}][/a]
It's standardized? It has better performance for high bitrates/sampling rates? It supports good rates with float data?
Apart from a smaller filesize, what's so exciting about ANOTHER lossless format? Are there really not enough different audio-formats out there, not just to mention all the different lossless formats????
Speaking as a person with a significant amount of time and effort invested in a CD collection that is now all on my hard drive as flac files...
Standards. And the hope of the benefits of standards.
Yes, there ARE too many lossless formats already. And none of them has been adopted by everyone, since none has a clearly compelling advantage.
A format being accepted as a standard by a major industry group is an advantage. If that fact causes it to be supported by Most Major Platforms (i.e.: supported out of the box by OS-X, Windows, and Unix variants such as Linux, supported out of the box on i-Pod and many MP3 players).
If that happened, I'd gladly take the time (ok, it would just be a script this time) to convert my flac files to THAT format.
*If* that happened...
Mark
"The nice thing about standards is that there are so many of them to choose from."
-- Andrew S. Tanenbaum
Is there a directshow/winamp/etc decoder available?
Tested the reference encoder on my benchmark, second place after OptimFROG:
http://uclc.info/lossless_audio_compression_test.htm (http://uclc.info/lossless_audio_compression_test.htm)
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.
minor nit: the codec is licensed bsd-like:
The reference implementation libraries are licensed under Xiph's variant of the BSD License, a.k.a. the Xiph License.
Hey, guys, can anyone tell me what the command-line settings for EAC are?..
Or there are no such settings at all?..
Seems like there is a bug fixed version (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4alsRM16fixed.zip) and a new release expected for this month according to T. Liebchen.
http://www.nue.tu-berlin.de/forschung/proj....html#downloads (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html#downloads)
Just out of curiosity, what does S in ALS stand for? It's "s" in "lossless"?
Just out of curiosity, what does S in ALS stand for? It\'s \"s\" in \"lossless\"?
\"MPEG-4 Audio Lossless Coding (ALS)\"
are you saying it's a recursive acronym? I don't think so.
are you saying it\\\'s a recursive acronym? I don\\\'t think so.
form wiki
Audio Lossless Coding, also known as MPEG-4 ALS, is an extension to the MPEG-4 audio standard to allow lossless audio compression. The extension was finalised in December 2005.
are you saying it\\\'s a recursive acronym? I don\\\'t think so.
form wiki
Audio Lossless Coding, also known as MPEG-4 ALS, is an extension to the MPEG-4 audio standard to allow lossless audio compression. The extension was finalised in December 2005.
What are you trying to say?
MPEG-4 ALS stands for Audio Lossless Coding
or there is another explanation of MPEG-4 ALS
Yes, we know what it stands for, but where does the ALS come fron?
Audio Lossless S...?
I guess it's probably the S from Lossless as the original poster also thought.
Considering
Audio Lossless Coding = ALS
and
Scalable Lossless Coding = SLS,
perhaps LS stands for "Lossless" here. Still.... it could have been ALC and SLC just like
Advanced Audio Coding = AAC
and
Advanced Video Coding = AVC.
The news release, "MPEG-4 ALS (audio lossless coding)" is ready (http://www.ntt.co.jp/news/news05e/0512/051227.html) says "14496-3 3rd ED AMD 2 (ALS): MPEG-4 audio 3rd edition amendment 2. It is usually called as ALS." in its <Terminology> section, but why it is "usually called" so is unclear.
Just a random interest
MPEG-4 Audio Lossless Coding (ALS) Standard
this is only my theory
I think that it is Audio-LS (lossless), in a similar naming to JPEG-LS
Seems like there is a bug fixed version (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4alsRM16fixed.zip) and a new release expected for this month according to T. Liebchen.
http://www.nue.tu-berlin.de/forschung/proj....html#downloads (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html#downloads)
The promised new release is now out. Along with a new interesting promise as well (a WinAmp plugin in the next few days).
As far as I can see, only a small bugfix. Still no sign of MP4 embedding or at least a reference file for that (was promised months ago).
They are going to release a Winamp plugin before they finish MP4 embedding? Yeah, let's spread those .ALS files instead of proper containers. Perhaps we can even tack ID3v2 on them, hah!
Please tell me it ain't so.
Not the most popular format around at the moment, but, in case someone is interested:
RM18 (available 22 September 2006): Will additionally include full MP4 file format support (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html#downloads)
They took nine months to give birth to the mp4 solution
From what I gather, this encoder is ok for end-user, but not ok for distribution in a freeware or commercial product?
just a stupid lil question here... will lossless formats ever reach 5:1 on the source? or is that technically impossible to do?
just a stupid lil question here... will lossless formats ever reach 5:1 on the source? or is that technically impossible to do?
"what source?"
Hi all. I am ewby on this forum. For me i s very interesting to read all those things you guys write. But to the moment i did not understand wich software do you using to encode wav,s to MPEG 4 losless. I am using foobar2000 to encode all my cd collection to WavPack. But i am wondering to try this new format too. But i do not know how 10x
"what source?"
CD PCM for example.... FLAC does it 2:1.... will it ever reach 5:1 ? Or technically impossible?
"what source?"
CD PCM for example.... FLAC does it 2:1.... will it ever reach 5:1 ? Or technically impossible?
FLAC does not compress 2:1 in the general case. It's more like 1.7:1, sometimes much more, sometimes almost nothing. That's why I said "what source"? These codecs do not have fixed compression ratios and vary a lot depending on music style.
On multichannel it might be possible in the future to achieve something like 5:1 lossless compression, but on 2 channels it seems quite unlikely (in the general case of course).
"what source?"
CD PCM for example.... FLAC does it 2:1.... will it ever reach 5:1 ? Or technically impossible?
For lossless 5:1 (average) is likely impossible. There are several algorithms used for lossless, though the average compression ratio does not vary much between them. Usually 1.5-2.5:1
In theory it's possible for certain data sets to actually be enlarged when attempting to losslessly compress.
See:
http://www.faqs.org/faqs/compression-faq/p.../section-4.html (http://www.faqs.org/faqs/compression-faq/part2/section-4.html)
The entire compression FAQ is good, though a little dated. I don't think much has changed since it was created in 99:
http://www.faqs.org/faqs/compression-faq/part1/ (http://www.faqs.org/faqs/compression-faq/part1/)
Really I don't think there's much of a need as lossy (mp3) is now so good, and it gives an outstanding 10:1 compression ratio with little quality loss. Usually provides a good approximation of the original signal, at least to human ears. It's just a much more intelligent way to compress audio as it makes assumptions based on weaknesses in human perception (less senstive to high frequencies, masking effects) and it combines both a compact mathematical representation (MDCT) with huffman coding (additional compression). It also assumes you have a fast enough computer to transform things back to the time domain 'real time' - these days a safe assumption
Still the lossless compression is an interesting problem. It would be nice to get another factor of two - say 4:1. Lately I've been wondering if there might be some way to trade processing power for a greater lossless compression ratio. It might be possible, but if it takes a day to compress a CD I doubt many people would want to use the program.
Somebody needs to think of a new approach.
Not the most popular format around at the moment, but, in case someone is interested:
RM18 (available 22 September 2006): Will additionally include full MP4 file format support (http://www.nue.tu-berlin.de/forschung/projekte/lossless/mp4als.html#downloads)
Ok, reference encoder with mp4 support is available now but not playable yet. Sweet......
Ok, reference encoder with mp4 support is available now but not playable yet. Sweet......
Moreover Windows COMP is suggesting me that files producted by RM18 seems to be identical to RM17 ones...
Anyway, this encoder shows some uncommon behaviour. Without intentionally looking for limit conditions, in my standard 26 files corpus SetF I have:
MP4ALS RM17 -7 -n2560 -o32 64,19%
LA v0.4b high 65,99%
OptimFrog v4.600exp ultranew experimental 66,16%
Monkey v4.01 Insane 66,34%
on one of the samples, showing a "-o32" MP4ALS mode compressing 1,8% - 2,2% more than best LA, OFR and APE modes. Nice. On the other hand, on other two samples I have:
OptimFrog v4.600exp fast 55,05% 45,42%
Yalac v0.11 fast 55,80% 49,36%
Monkey v4.01 fast 58,01% 49,48%
WavPack v44a3 -hh 60,30% 49,83%
MP4ALS RM17 -7 -p -t2 60,68% 50,09%
which shows best MP4ALS mode compressing 2% - 5% worse than OFR, YAA, APE fast modes and also slightly worse than WV -hh. I know that codec performance strongly depends on the set you're using (and that this particular encoder is said to be immature, even if this same behaviour is shared by its predecessor LPAC), but that is maybe far too much.
Every encoder has its high and low peaks but in my experience (and checking the various comparison pages around) MP4ALS performance variability looks much higher than every other modern codec. Nevertheless its peak performances are very interesting and I'm really hoping some of the talented guys around will give us a better version, someday...
That is not to talk about decoding speed: in the same set (at -7 -p -t2), slowest file decodes around 7 times slower than fastest one...
which shows best MP4ALS mode compressing 2% - 5% worse than OFR, YAA, APE fast modes and also slightly worse than WV -hh.
Best mode should be -z3, not -7 -p -t2
Garf, do you still have the patch for some optimizations ?
Anyway, this encoder shows some uncommon behaviour. Without intentionally looking for limit conditions, in my standard 26 files corpus SetF I have:
MP4ALS RM17 -7 -n2560 -o32 64,19%
LA v0.4b high 65,99%
OptimFrog v4.600exp ultranew experimental 66,16%
Monkey v4.01 Insane 66,34%
on one of the samples, showing a "-o32" MP4ALS mode compressing 1,8% - 2,2% more than best LA, OFR and APE modes. Nice.
Josef, I think this is a rather extraordinary result! Would it be possible for me to get this sample to see if I can find anything special about it?
Thanks in advance.
David
Garf, do you still have the patch for some optimizations ?
No, this format isn't going anywhere anyway.
Best mode should be -z3, not -7 -p -t2
You're obviously right, my mistake. When speed is not an issue '-z3' is a totally different story. Still a little slower, better compression, stable performance level.
And it shows no wonder:
MP4ALS RM17 -7 -n2560 -o32 64,19%
LA v0.4b high 65,99%
OptimFrog v4.600exp ultranew experimental 66,16%
Monkey v4.01 Insane 66,34%
MP4ALS RM17 -z3 -p -t2 -b 66,42%
and no shame:
MP4ALS RM17 -z3 -p -t2 -b 53,69% 43,38%
OptimFrog v4.600exp fast 55,05% 45,42%
Yalac v0.11 fast 55,80% 49,36%
Monkey v4.01 fast 58,01% 49,48%
WavPack v44a3 -hh 60,30% 49,83%
MP4ALS RM17 -7 -p -t2 60,68% 50,09%
That said, in my opinion things do not change that much. It still looks a little odd to see a '-o32' mode over 2% better than a '-z3' mode on the first sample and an almost 7% gap between '-z3' and '-7' on the other ones.
...would it be possible for me to get this sample to see if I can find anything special about it?
Of course! I hope you got my PM. Though currently I'm not done with it, on the same sample the second best encoder is... RkAu!
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.
How does mp4 als relate to AAC-HD (which Fraunhoffer are promoting)?
mpeg4als RM18 released
uri: http://www.nue.tu-berlin.de/research/proje....html#downloads (http://www.nue.tu-berlin.de/research/projects/lossless/mp4als.html#downloads)
-MP4 option implemented, but can't play at present
"test.mp4":
Track Type Info
1 audio MPEG-4 Unknown Profile(31), 343.066 secs, 440 kbps, 44100 Hz
How does mp4 als relate to AAC-HD (which Fraunhoffer are promoting)?
Got a link? Never heard of it.
Got a link? Never heard of it.
Fraunhofer IIS - Audio & Multimedia Realtime Systems - Lossless Audio Coding (http://www.iis.fraunhofer.de/amm/projects/losslessaudio/)
http://www.iis.fraunhofer.de/amm/projects/...udio/index.html (http://www.iis.fraunhofer.de/amm/projects/losslessaudio/index.html)
So "HD-AAC" is really MPEG-4 SLS. It has nothing in common with ALS except that they can both operate in lossless mode.
mpeg4als RM18 released
uri: http://www.nue.tu-berlin.de/research/proje....html#downloads (http://www.nue.tu-berlin.de/research/projects/lossless/mp4als.html#downloads)
-MP4 option implemented, but can't play at present
"test.mp4":
Track Type Info
1 audio MPEG-4 Unknown Profile(31), 343.066 secs, 440 kbps, 44100 Hz
I submitted some changes to let MPEG-4 ALS show correctly in tools built on MPEG4IP. Bill checked them into CVS, but they aren't in an official release yet. Still can't play them though
I submitted some changes to let MPEG-4 ALS show correctly in tools built on MPEG4IP. Bill checked them into CVS, but they aren't in an official release yet. Still can't play them though
Wow!! good news!! thx benski
I'm waiting for an official release of new winamp or fb2k
I heard that it is backward compatible with AAC.
What is the compression ratio like?
Check out this website in Singapore about MPEG4-ALS.
http://www.a-star.edu.sg/astar/about/actio...id=0e10c9198dYF (http://www.a-star.edu.sg/astar/about/action/pressrelease_details.do?id=0e10c9198dYF)
Check out this website in Singapore about MPEG4-ALS.
http://www.a-star.edu.sg/astar/about/actio...id=0e10c9198dYF (http://www.a-star.edu.sg/astar/about/action/pressrelease_details.do?id=0e10c9198dYF)
It's about SLS, which is something
entirely different.
Check out this website in Singapore about MPEG4-ALS.
http://www.a-star.edu.sg/astar/about/actio...id=0e10c9198dYF (http://www.a-star.edu.sg/astar/about/action/pressrelease_details.do?id=0e10c9198dYF)
It's about SLS, which is something entirely different.
Now I am really confused... SLS or ALS or HD-AAC???
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
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!
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!
http://www.hydrogenaudio.org/forums/index....st&p=436279 (http://www.hydrogenaudio.org/forums/index.php?showtopic=40124&view=findpost&p=436279)
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.