IPB

Welcome Guest ( Log In | Register )

5 Pages V   1 2 3 > »   
Reply to this topicStart new topic
WOW, Monkey's Audio is still the best, Ya better believe it
adlai
post Sep 22 2006, 23:35
Post #1





Group: Members
Posts: 318
Joined: 29-November 03
Member No.: 10090



I did a comparison between Flac, Wavpack, and Monkey's Audio. I'm a longtime MAC user, but I've been considering replacing it with something else.

Monkey's Audio still has the smallest file sizes, and the fastest compression. On a test sample, the FLAC file was around 53 MB, the Wavpack was 51, and the Monkey's Audio was 47. Additionally, the monkey's audio on a whole encoded at a faster rate.

Yes, I know that FLAC and Wavpack have features that MAC doesn't, most noticably lossy and better seeking. However, I use lossless only for archival purposes-- I rarely actually listen to the files, and so, I have to say that monkey's audio is still the best smile.gif
Go to the top of the page
+Quote Post
pest
post Sep 22 2006, 23:44
Post #2





Group: Members
Posts: 208
Joined: 12-March 04
From: Germany
Member No.: 12686



QUOTE
that monkey's audio is still the best smile.gif


Me too biggrin.gif
It was the first codec i tried that worked with embedded cue-files in foobar2000.
Decoding speed is good enough even at Extra-High.
I really can't think of any good reason to use one of the others if hw-support is of little concern.

edit: the seeking issues you mentioned where in the old versions < 4.x for Modes > High

This post has been edited by pest: Sep 22 2006, 23:47
Go to the top of the page
+Quote Post
HbG
post Sep 22 2006, 23:48
Post #3





Group: Members
Posts: 289
Joined: 12-May 03
From: The Hague
Member No.: 6555



I'm not so sure about the fastest. Flake is a flac encoder that's three times faster and produces slightly better compression as well.

I went from ape to flac a while ago, i decided flac's decoding speed, support, features and robustness were worth the few extra megabytes.


--------------------
Veni Vidi Vorbis.
Go to the top of the page
+Quote Post
Shade[ST]
post Sep 23 2006, 01:01
Post #4





Group: Members
Posts: 1189
Joined: 19-May 05
From: Montreal, Canada
Member No.: 22144



And wait until you try out TAK (Yalac)
Go to the top of the page
+Quote Post
kanak
post Sep 23 2006, 04:07
Post #5





Group: Members
Posts: 1190
Joined: 12-January 06
From: Cambridge, MA
Member No.: 27052



Totally agree with shade. i'm so excited by this new codec. Can't wait to get my hands on it.
Go to the top of the page
+Quote Post
Mangix
post Sep 23 2006, 04:13
Post #6





Group: Members
Posts: 587
Joined: 26-February 06
Member No.: 28077



OptimFROG should be able to compress better than Monkey's Audio
Go to the top of the page
+Quote Post
LANjackal
post Sep 23 2006, 06:48
Post #7





Group: Members
Posts: 731
Joined: 26-October 05
From: Various networks
Member No.: 25371



QUOTE (adlai @ Sep 22 2006, 18:35) *
Yes, I know that FLAC and Wavpack have features that MAC doesn't, most noticably lossy and better seeking. However, I use lossless only for archival purposes-- I rarely actually listen to the files, and so, I have to say that monkey's audio is still the best smile.gif


I too use MAC lossless for archiving only, and so came to the same conclusion as yourself. Your premise is strongly seconded from this side of the world smile.gif.

Granted, however, if I actually did use lossless for playback I'd opt for FLAC.


--------------------
EAC>1)fb2k>LAME3.99 -V 0 --vbr-new>WMP12 2)MAC-Extra High
Go to the top of the page
+Quote Post
Duble0Syx
post Sep 23 2006, 07:38
Post #8





Group: Members
Posts: 465
Joined: 2-May 04
Member No.: 13847



QUOTE (LANjackal @ Sep 22 2006, 21:48) *
QUOTE (adlai @ Sep 22 2006, 18:35) *
Yes, I know that FLAC and Wavpack have features that MAC doesn't, most noticably lossy and better seeking. However, I use lossless only for archival purposes-- I rarely actually listen to the files, and so, I have to say that monkey's audio is still the best smile.gif


I too use MAC lossless for archiving only, and so came to the same conclusion as yourself. Your premise is strongly seconded from this side of the world smile.gif.

Granted, however, if I actually did use lossless for playback I'd opt for FLAC.

If one only uses lossless for archiving, why is compression speed an issue? OptimFrog most likely offers the best compression. MAC is indeed a good codec, if I were archiving I'd still probably use FLAC or WavPack though. I like the licensing on the source code. smile.gif Ensure's they'll still be around in the future.
Go to the top of the page
+Quote Post
halb27
post Sep 23 2006, 09:43
Post #9





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



When I did lossless archiving I was very happy with Monkey.
Good speed when encoding and decoding even in extra high mode, and a compression ratio better than FLAC or wavPack, and which I don't expect to be significantly outclassed even with highly compression-effective super-slow codecs.


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
evereux
post Sep 23 2006, 09:44
Post #10





Group: Members
Posts: 907
Joined: 9-February 02
From: Cheshire, UK
Member No.: 1296



Here's some informative links on Lossless codecs, ya better beleive it.

http://wiki.hydrogenaudio.org/index.php?ti...less_comparison

http://uclc.info/LossLess.pdf
http://web.inter.nl.net/users/hvdh/lossless/lossless.htm
http://synthetic-soul.co.uk/comparison/lossless/


--------------------
daefeatures.co.uk
Go to the top of the page
+Quote Post
guruboolez
post Sep 23 2006, 09:57
Post #11





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



QUOTE (adlai @ Sep 23 2006, 00:35) *
Monkey's Audio still has the smallest file sizes, and the fastest compression.

Indeed, Monkey's Audio is still excellent in this area. But it also has poorer performance on decoding speed (which makes hardware support harder), a bit like OptimFROG (even slower). Error handling (decoding after media corruption, bad transfert...) is also a weak point for this format; and since 3.99 and with -c4000/5000 profiles only files are usually suffering from a long starting time making gapless playback impossible.
Some other formats are performing better in different area than ratio & encoding speed.

This post has been edited by guruboolez: Sep 23 2006, 09:58
Go to the top of the page
+Quote Post
halb27
post Sep 23 2006, 10:03
Post #12





Group: Members
Posts: 2428
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



QUOTE (evereux @ Sep 23 2006, 10:44) *

Well, these results show up the quality of Monkey very well.
Only LA is really interesting when compression ratio has a very strong weight. But compression ratio is not a lot better than Monkey's but encoding and decoding speed is significantly lower.
Moreover while Monkey extra high means very good compression and good speed when speed is more of concern high and normal mode make Monkey pretty fast whereas compression ratio doesn't suffer a lot.

EDITED:
I should add that the application context is most of concern of course. A codec like Monkey is interesting only for archiving and/or for listening to on a pc. When going for other listeninig environments I think there is no alternative to FLAC or wavPack (which are good solutions anyway - cause among all the good lossless codecs there's no big difference in compression ratio).

This post has been edited by halb27: Sep 23 2006, 10:12


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
Leo 69
post Sep 23 2006, 10:09
Post #13





Group: Members
Posts: 121
Joined: 16-May 04
From: UK - Russia
Member No.: 14117



QUOTE
Error handling (decoding after media corruption, bad transfert...) is also a weak point for this format;


guruboolez, is that in theory or in practice ? Any links to real problem reports regarding this ?
Go to the top of the page
+Quote Post
seanyseansean
post Sep 23 2006, 10:21
Post #14





Group: Members (Donating)
Posts: 487
Joined: 12-August 02
From: Cheltenham, UK
Member No.: 3029



QUOTE (Leo 69 @ Sep 23 2006, 10:09) *
QUOTE
Error handling (decoding after media corruption, bad transfert...) is also a weak point for this format;


guruboolez, is that in theory or in practice ? Any links to real problem reports regarding this ?


When I used to use monkeys audio there were a lot of times files were corrupted, compared to the two corrupted flac files i've ever seen. No, I don't overclock, neither do I use beta drivers or otherwise tune the bejesus out of my machines. I never worked out whether these were encode/decode errors or hardware related as I never verified them after creation due to my own laziness.

I liked monkeys audio but it always seemed like an unfinished project to me.
Go to the top of the page
+Quote Post
guruboolez
post Sep 23 2006, 10:32
Post #15





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



QUOTE (Leo 69 @ Sep 23 2006, 11:09) *
QUOTE
Error handling (decoding after media corruption, bad transfert...) is also a weak point for this format;


guruboolez, is that in theory or in practice ? Any links to real problem reports regarding this ?

In practice. There are old discussions on this board with samples showing how are reacting different decoders on corrupted streams. You can try yourself and simulate a data corruption with any hexadecimal editor.
I was myself a satisfied MAC's user, and I only obtained two corrupted files (on thousands):
- one appeared with no explanation
- the second one appeared after a partition lost and a data restauration (I was able to recover a proper file after a second restauration).

It's with DVD-R backups that the way different formats/decoders are handling corrupted stream started to become important to my eyes. Previously I didn't really care about it.

This post has been edited by guruboolez: Sep 23 2006, 10:33
Go to the top of the page
+Quote Post
spoon
post Sep 23 2006, 11:05
Post #16


dBpowerAMP developer


Group: Developer (Donating)
Posts: 2745
Joined: 24-March 02
Member No.: 1615



>c4000/5000 profiles only files are usually suffering from a long starting time making gapless playback impossible

That is more down to the software trying to do gapless, rather than the format.

About corrupt files (I have also run tests with FLAC - changing a single byte in 30 different places, with pretty much the same results as Monkeys). The whole idea about lossless is either it is perfect or it is not, if it is not, recreate it - so the important factor of lossless is the ablity to error check the decoded data - as FLAC and Monkeys have md5 emdedded there are no issues there.


--------------------
Spoon http://www.dbpoweramp.com
Go to the top of the page
+Quote Post
guruboolez
post Sep 23 2006, 11:23
Post #17





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



I got completely different results with FLAC/WavPack than with Monkey's. Moreover, the amount of lost datas seems to depend on the encoding profile (the silent part which replaces music is longer with highest profile). I'm not completely sure about it (I experimented it, but I didn't bother to reproduce the same with several samples).
In other words, corruption may appear as less annoying with one format/profile than with one another.

For gapless: I also read once that file buffering should explain this issue. Are there players able to read these encodings without problems?
Go to the top of the page
+Quote Post
askoff
post Sep 23 2006, 13:06
Post #18





Group: Members
Posts: 445
Joined: 23-December 02
Member No.: 4214



MAC doesn't seem to be available for Linux or any other OS than Windows. It's not a problem for most people but not all people use Windows (only). I for one am trying to get away from Windows dependency.
Go to the top of the page
+Quote Post
guruboolez
post Sep 23 2006, 13:09
Post #19





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



Monkey's code is avaible since 2003 or 2004. Linux and MacOS ports exist for a long time. Just google for it
example: http://sourceforge.net/projects/mac-port/

This post has been edited by guruboolez: Sep 23 2006, 13:11
Go to the top of the page
+Quote Post
askoff
post Sep 23 2006, 14:40
Post #20





Group: Members
Posts: 445
Joined: 23-December 02
Member No.: 4214



I see. I haven't seen that before. Well I haven't been realy looking for it since I stopped using MAC. There was no mention of Linux in monkeysaudio.com, so I assumed that it doesn't exist. It's good that it does.
Go to the top of the page
+Quote Post
IgorC
post Sep 23 2006, 14:44
Post #21





Group: Members
Posts: 1556
Joined: 3-January 05
From: ARG/RUS
Member No.: 18803



Well. Monkey is 5% more efficient than FLAC SVN 2006. But is it really making sense this 5% compression gain ( approx 15 mb per cd) when DVDs blank cost cents? I.e. 300-450 mb per cd - 10-15 CD flacs per DVD. And with Monkey Highest Profile you will hardly get 16th cd.
While decoding FLAC (for future mp3 rip for player ) whole album is geting less than 1 minute!!!! Monkey goes for at least a few minutes.
Go to the top of the page
+Quote Post
MedO
post Sep 23 2006, 15:23
Post #22





Group: Members
Posts: 341
Joined: 24-August 05
Member No.: 24095



QUOTE (IgorC @ Sep 23 2006, 15:44) *
Well. Monkey is 5% more efficient than FLAC SVN 2006. But is it really making sense this 5% compression gain ( approx 15 mb per cd) when DVDs blank cost cents? I.e. 300-450 mb per cd - 10-15 CD flacs per DVD. And with Monkey Highest Profile you will hardly get 16th cd.
While decoding FLAC (for future mp3 rip for player ) whole album is geting less than 1 minute!!!! Monkey goes for at least a few minutes.


I found it easier to fit two compressed albums on one CD-R with Monkey's... some albums just remained so big that they accumulated dust on my HD waiting for a matching small album, so I could put them in my archive. Of course I could have just burned the single album, but that would have been a waste of space laugh.gif .
I've just recently changed back to Flac, because of the faster encoding times and broader support of the format, which makes it more future-safe for my archive. The fit is now easier because I no longer put recovery information on the CD itself, but rather on a dedicated CD along with the recovery data for 5 others.
Go to the top of the page
+Quote Post
LoFiYo
post Sep 23 2006, 16:51
Post #23





Group: Members
Posts: 133
Joined: 2-January 04
Member No.: 10896



If you are worried about the filesize only, LA may be worth a try. Either last year or before that, I tried it and it compressed better than APE or FLAC or WV. But then, other codecs may beat it by now. tongue.gif
Go to the top of the page
+Quote Post
greynol
post Sep 23 2006, 17:27
Post #24





Group: Super Moderator
Posts: 10000
Joined: 1-April 04
From: San Francisco
Member No.: 13167



QUOTE (guruboolez @ Sep 23 2006, 03:23) *
In other words, corruption may appear as less annoying with one format/profile than with one another.

"Less annoying" is hardly grounds for saying one has robustness and the other doesn't, no?

This talk about robustness and error handling in the wiki is a bunch of BS!


--------------------
I should publish a list of forum idiots.
Go to the top of the page
+Quote Post
rjamorim
post Sep 23 2006, 17:35
Post #25


Rarewares admin


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



QUOTE (spoon @ Sep 23 2006, 07:05) *
The whole idea about lossless is either it is perfect or it is not


Nope, the idea is also about archival. And being able to recreate most of your music is better than not being able to recreate anything. That's the problem with Monkey's.


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

5 Pages V   1 2 3 > » 
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: 27th August 2014 - 20:53