Skip to main content ↑ ↓

Notice

If you are using a Hotmail or Outlook email address, please change it now, as Microsoft is rejecting all email from our service outright.
Topic: WOW, Monkey's Audio is still the best (Read 64968 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

WOW, Monkey's Audio is still the best

Reply #25 –
Quote from: rjamorim on
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.

Again, more FUD BS about MAC.

WOW, Monkey's Audio is still the best

Reply #26 –
Yeah, way too paranoid - unless you sold your CD's or something and even then its a one in a million event.
wavpack 4.8 -b3hx4cl
 

WOW, Monkey's Audio is still the best

Reply #27 –
Some people are under the assumption that it is impossible to decode through errors with a file created using MAC.

This simply isn't true.

WOW, Monkey's Audio is still the best

Reply #28 –
Decoding is possible but the loss is more important than with WavPack or FLAC. That's why I said that error handling could be less annoying with other formats than MAC. Samples were posted on the board in the past to illustrate this issue. If the situation has changed, or if your experience is different, may I suggest you to enlight people with some facts others than "BS" and "FUD" expression? People would be happy to learn something.

WOW, Monkey's Audio is still the best

Reply #29 –
I know what you said, guruboolez; and in light of what you said, don't you think it's incorrect to claim that flac has robustness to errors and MAC does not?  Don't you think the graph in the wiki is at least misleading if not incorrect?

I very much stick to my comments about FUD BS and I provided the board with a simple fact:
Quote
Some people are under the assumption that it is impossible to decode through errors with a file created using MAC.

This simply isn't true.

If someone wants to know how, I'll gladly tell them.  As of yet, no one has asked.

WOW, Monkey's Audio is still the best

Reply #30 –
Quote from: greynol on
I know what you said, guruboolez; and in light of what you said, don't you think it's incorrect to claim that flac has robustness to errors and MAC does not?  Don't you think the graph in the wiki is at least misleading if not incorrect?

The WIKI mentions "error handling"; "NO" for MAC and "YES" for FLAC. I don't have that much experience with Monkey's. From my limited one, I achieved to decode corrupted .ape files but in my souvenirs I also get one file I wasn't able to fully recover. So I wouldn't answer to your question without further investigations. Anyway, corruption is doing more harm with APE format than with WavPack/FLAC. In my opinion, this count as advantage in error handling and robustness feature.

I also recall that the WIKI is a collective project - so if you notice some errors I suppose that you should correct it without any problem and differently than making noise with several "BS... and I'm ready to tell you why you're wrong but only if you ask me first". It's not a very constructive attitude

WOW, Monkey's Audio is still the best

Reply #31 –
You are talking in shades of gray.  That portion of the table in the wiki is black and white.  Because flac is able to retain more data after corruption than MAC doesn't mean that it should get a different entry for error handling.  Both formats can decode through errors and both formats lose data in the process.

No matter what you think of my attitude, saying that you'll loose all of your data if there is corruption when using MAC is BS FUD.  I'm sorry that you don't like the way I addressed the issue.  I can only hope that you would also take exception to rjamorim's erroneous statement.

--> Anyway, to clear the air over how, Winamp will do it and I think dBpowerAMP will too. <--

Thanks for clueing me in on the WIKI and I would suggest that it be changed, but bashing Monkey's Audio is practically a sport on this forum and it has gotten quite tiresome for me.  In my mind your rationale for why flac gets a "Yes" and MAC gets a "No" is just a continuation of this bias.

WOW, Monkey's Audio is still the best

Reply #32 –
Quote from: greynol on
No matter what you think of my attitude, saying that you'll loose all of your data if there is corruption when using MAC is BS FUD.

Is "BS FUD" a simple synonymous of "mistake"? Or isn't this expression a bit more pejorative?
You have the power of correcting each mistake in the WIKI - so if you're not interested to improve it, why don't you just ignore it?

Quote
but bashing Monkey's Audio is practically a sport on this forum and it has gotten quite tiresome for me.

Ah, the good old conspiracy theory

WOW, Monkey's Audio is still the best

Reply #33 –
Quote
Is "BS FUD" a simple synonymous of "mistake"?
No.

Quote
Or isn't this expression a bit more pejorative?
No.

We're talking about perpetual propagation of misinformation, not a simple mistake, but you can paint it any way you like.

WOW, Monkey's Audio is still the best

Reply #34 –
I've been using Monkey's Audio for close to two years now, and am up to almost 8,400 files. I've never had a file become corrupt on me in that time, and I do use them for playback on a regular basis, nearly every day in fact. I also transcode from them to lossy formats when needed, like OGG Vorbis for my Rio Karma (man I love foobar2000!). I use Monkey's Audio at the -c3000 setting mainly because I feel it's the best compromise between encode speed, decode speed, CPU usage, and especially file size. All my files at FLAC level 8 take up about 10 to 11 gigabytes more space, so clearly it does tend to add up quite quickly. If speed and CPU usage were the most important thing to me, then I would probably use FLAC, especially where wider support becomes important. I also think WavPack is probably the best compromize between those two formats, having some of the better aspects of each. So they're all good for their own individual reasons, but I've tended to stick with Monkey's primarily because of file sizes.

WOW, Monkey's Audio is still the best

Reply #35 –
Quote from: greynol on
We're talking about perpetual propagation of misinformation, not a simple mistake, but you can paint it any way you like.

This is getting funny... if you are that hesitant in enlightening guruboolez (as well as the rest of us), then I guess I can paint it that you are as guilty as him in maintaining the state of misinformation.

"I can assure you Abe Lincoln wasn't assassinated, now please change the history books based on my oneliner assurance thankyouverymuch."

In the same painting, thanks, Digisurfer. 8400 files is quite a solid testimony

WOW, Monkey's Audio is still the best

Reply #36 –
Do you honestly want me to start citing all the unfounded criticism about Monkey's Audio here?  You guys act as if you're asking for the impossible.

I seriously believe that MAC gets a bad wrap in this forum.  This is my opinion based on my own personal perception.  If you want to set up strawman arguments about aliens, Abe Lincoln and who knows what else, be my guest.

It isn't like I'm the only one who has ever used the terms BS and FUD on this forum; and I honestly think such terms are appropriate here.  But if you all think that I owe guruboolez and rjamorim apologies, they can each have one.  If you want me to roll over and allow the BS and FUD regarding MAC to continue or even (gasp) buy into it, forget about it.

Now, can anyone tell me why MAC gets a different rating than flac in the wiki when it comes to error handling?

WOW, Monkey's Audio is still the best

Reply #37 –
I think the whole point of this topic is basically that MAC is "Still the best."  Which is of course arguably not true.  From the originally posters viewpoints and uses it may well be the best.  However I think overall plenty of other lossless compressors are better.  And about the error handling, I think when decoding a corrupted file you lose more frames with MAC on average than other codecs like FLAC or WavPack.  The only thing MAC is really good at is slightly higher compression ratio's.  The negatives are much more apparent, as already mentioned.  It gets a bit of bad rap for plenty of reasons.  I think plenty of people have overly high opinions of it as well.  That's why this is a discussion forum, and why there a tons of lossless codecs out there.  To each their own.

WOW, Monkey's Audio is still the best

Reply #38 –
Barring how one would subjectively weight certain aspects when considering the best overall lossless encoder, I totally agree.

I would stick up for any lossless codec that is being incorrectly and unfairly criticized.

EDIT: BTW, I'm dead serious about the question regarding error handling.  If MAC is no, flac should be no also; data loss is data loss.

EDIT #2:  In good faith, I apologize to rjamorim for appearing to have singled him out for his comments.  I apologize to rjamorim, guruboolez and the entire group for wasting your time arguing over a disagreement in opinion and appearing evasive instead of offering up constructive statements and proof to support my criticism which all the while was easily at my disposal.

I am interested in improving the wiki and feel that it should be changed, otherwise I would have never gotten involved in this discussion to the extent that I have.

WOW, Monkey's Audio is still the best

Reply #39 –
MAC is still the best lossless codec (that I can recommend).

Back when I started using it in 1999, it had extra's like a GUI frontend, Winamp plugin and Cooledit filter that no other package had at the time. It performed amazingly fast even on my AMD K6-2. I was hooked. Never went back but I also manitain a uniform archive, so I've been using that same outdated version of MAC at Normal compression ever since. Better things to do than worry about than the bleeding edge of lossless encoding when long-term archival is the goal. I can't say I'm unhappy with my choice of codec, although I found Yalac to be most interesting when it comes to its competitive ration and asymetrical encoding/decoding.
"Something bothering you, Mister Spock?"

WOW, Monkey's Audio is still the best

Reply #40 –
Quote from: greynol on
I am interested in improving the wiki and feel that it should be changed, otherwise I would have never gotten involved in this discussion to the extent that I have.

1. Click on Wiki on top of this page
2. Click "Log in / create account"
3. Click "Create account"
4. Enter user name and password and validate
5. Request and obtain editing rights from Jan S.
6. Click on "Lossless Comparison"
7. Click "Edit"
8. Change the appropriate value from "no" to "yes" and validate

Done!

WOW, Monkey's Audio is still the best

Reply #42 –
I've just checked MAC 4.01 latest build error handling. I used a small sample (15 seconds) and I 'corrupted'  one string with UltraEdit.

String 00000800h original data:
BF 6B 76 4A DE 62 65 AC CO E4 5B 35 E4 16 04 7A
Now it's:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I did the same operation with a WavPack encoding

String 00000800h original data:
12 22 3B 1F B1 4E 74 CD 3C 7F 8C 31 5A 8D 64 CB
Now it's:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

For conveniance, both versions (the clean and the corrupted files) are uploaded (see on bottom)




RESULTS:

• foobar2000 0.94
WavPack: the beginning (~1 sec) is missing; the rest is fine
Monkey's Audio: the player report an error; no music at all

• Winamp 5.25 (with latest plug-ins)
WavPack: the beginning (~1 sec) is missing; the rest is fine
Monkey's Audio: the player report an error and suggest to turn an option off in the settings. After this change, the playback doesn't stop but as music I only get 15 seconds of pure silence. From Mozart I switched to John Cage...
Same results with diskwriter.

• Adobe Audition 1.5 (with latest plug-ins)
WavPack: the beginning (1 sec exactly ) is missing; the rest is fine. A CRC error was reported after full decoding.
Monkey's Audio: no decoding at all.

• dBPowerAmp /!\ NOT THE LATEST VERSION[/color]
WavPack: the beginning (1 sec exactly ) is missing; the rest is fine.
Monkey's Audio: no decoding at all. Reports the following error and create a 1Kb .wav file : CODEC decompression error for 'C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CORRUPTED.ape'



Could someone try on his side and tell me (us?) how to get some music back with this corrupted APE?



DOWNLOAD TEST FILE

http://rapidshare.de/files/34268010/APE_WA...UPTION.zip.html

WOW, Monkey's Audio is still the best

Reply #43 –
Quote from: guruboolez on
RESULTS:

• foobar2000 0.94

• Winamp 5.25 (with latest plug-ins)

• Adobe Audition 1.5 (with latest plug-ins)

• dBPowerAmp /!\ NOT THE LATEST VERSION[/color]

I would suggest, to additonally try a decompression with the native (?) compressors. Otherweise you will not know, if bad implementations of the plugins are responsible for a worse error tolerance.

I don't want to say, that the quality of the plugins isn't important for the rating of a compressor. But for me it would be more important to know, if there is any way (native compressor) to restore audio data from a corrupted file, or if it is definitely lost.

WOW, Monkey's Audio is still the best

Reply #44 –
Hmmm... I forgot to mention that I tried with MAC.exe before any other app. With no success at all: mac.exe always reported an error (code 1009 or sthg like that) and official GUI didn't helped (the process stopped when it detected wrong CRC).

The limited ability of mac.exe for this purpose is well known IIRC. It's probably why greynol didn't mentioned this tool but rather Winamp and dBpowerAmp - which appeared in the past (Winamp for sure) to handle error handling with some success whereas officiel mac.exe couldn't. My little test seems to confirm that mac.exe v.4.01 isn't suitable as well.


EDIT: yes, it's "error 1009".

WOW, Monkey's Audio is still the best

Reply #45 –
I would like to see the test with FLAC as well.

<edit> I have recently worked on Monkeys and put an option to pass decoding errors as information (which would give the same as Winamp - ie silence audio after the error).

From what I have seen of FLAC decoders, they all bug out if the reported error is not FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC, so the missmatch of a CRC on a frame will cause the decoder to stop.

WOW, Monkey's Audio is still the best

Reply #46 –
Just transcode one reference file into FLAC format


EDIT:  There are apparently padded datas at "00000800h". I tried to disable it (-P 0... is that right) but it doesn't work.

EDIT2: --no-padding doesn't give the expected result either... I should "corrupt" the file in another position.

WOW, Monkey's Audio is still the best

Reply #47 –
Interestingly this is what the "File Integrity Verifier" component says about your files gurubulez:

Code: [Select]
Item: "C:\Download\APE_WAVPACK_CORRUPTION\E37_PERIOD_CHAMBER_G_violin_pianoforte_CLEAN.ape"
No problems found.

Item: "C:\Download\APE_WAVPACK_CORRUPTION\E37_PERIOD_CHAMBER_G_violin_pianoforte_CLEAN.wv"
No problems found.

Item: "C:\Download\APE_WAVPACK_CORRUPTION\E37_PERIOD_CHAMBER_G_violin_pianoforte_CORRUPTED.ape"
Error: Unsupported format or corrupted file

Item: "C:\Download\APE_WAVPACK_CORRUPTION\E37_PERIOD_CHAMBER_G_violin_pianoforte_CORRUPTED.wv"
No problems found.


1 item could not be decoded.

List of undecodable items:
"C:\Download\APE_WAVPACK_CORRUPTION\E37_PERIOD_CHAMBER_G_violin_pianoforte_CORRUPTED.ape"

foobar2000 v0.9.4 (EDIT: forgot to mention...  )
File Integrity Verifier - v1.0.1
Monkey's Audio decoding support - v2.1.1

The corrupted WavPack file isn't even detected as being corrupt...  which is a bad thing.

WOW, Monkey's Audio is still the best

Reply #48 –
I just tried with FLAC. Due to what seems to be a consequence of padding, I couldn't "corrupt" the data on the same string than before. I tried to locate the beginning of the FLAC audio stream and I modified the original data at a position which should be approximately the same than with WavPack or Monkey's (sorry if I'm not clear).

The playback is fine ; I used foobar2000 bit-to-bit comparator to see if something happened. Result: only less than 100 ms are missing (~90 ms).
Setting used:
- flac -8
- flake -12

Result is the same for flac and flake. With Audition, the flake file contains 100 ms of silence at the beginning; the flac encoding immediatly starts on the first valid sample.
Files are currently uploaded ; link will be available in a few minutes.


EDIT: exact position of my "corruption" process:
FLAC = 00006000h
FLAKE= 00001a10h

EDIT2: The archive is here:
http://rapidshare.de/files/34277364/FLAC_F...UPTION.zip.html


EDIT3: fandango> I was completely ignorant about this interesting component  I had to recover 260 GB of lossless music this summer due to HDD corruption ; I was able to test the recovered FLAC files with the VUplayer app but I'm still looking for a way to check the integrity of the WavPack files. I dreamt about such foobar2000 components. I will look for it. Thanks !!!

EDIT4:
Code: [Select]
Item: "C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CLEAN.ape"
No problems found.

Item: "C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CLEAN.flac"
No problems found.

Item: "C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CLEAN.flake.flac"
No problems found.

Item: "C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CLEAN.wv"
No problems found.

Item: "C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CORRUPTED.ape"
Error: Unsupported format or corrupted file

Item: "C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CORRUPTED.flac"
Warning: Reported length is inaccurate : 0:14.384172 vs 0:14.279683 decoded

Item: "C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CORRUPTED.flake.flac"
No problems found.

Item: "C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CORRUPTED.wv"
No problems found.


1 item could not be decoded.
1 item decoded with minor problems.

List of undecodable items:
"C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CORRUPTED.ape"

List of decodable but problematic items:
"C:\temp audio\E37_PERIOD_CHAMBER_G_violin_pianoforte_CORRUPTED.flac"

WOW, Monkey's Audio is still the best

Reply #49 –
It seems that FB2K's wv decoder can't detect error in wv. wvunpack works properly for that purpose. (wv-verify)
 
SimplePortal 1.0.0 RC1 © 2008-2021