Hydrogenaudio Forums > Monkey's Audio 3.99 released

Full Version: Monkey's Audio 3.99 released

Hydrogenaudio Forums > Hydrogenaudio Forum > Validated News

Pages: 1, 2

Sebastian Mares

May 2 2004, 08:31

OK, here are my results for "Pink Floyd - Hey You" (used the MAC GUI as decoder):

WAV -> APE 3.97 -> WAV = Pass
WAV -> APE 3.99 (MAC.EXE) -> WAV = Pass
WAV -> APE 3.99 (foobar2000) -> WAV = Error

Before running the conversion I have made sure that none of the files contained any tags (or ReplayGain information).

Edit: All files are good when decoded using the foobar2000 diskwriter. It seems that the MAC GUI has problems with the foobar2000 encoded APE file.

Peter

May 2 2004, 09:36

Foo_ape Case uploaded before was vulnerable to field name length exploit in maclib, please redownload it. Old foo_ape bundled with foobar2000 0.8.1 was patched against this already, so if you didn't update you have nothing to worry about (other than 3.99 files not working).
Alternatively, patched foo_ape is available here.

Sebastian Mares

May 2 2004, 10:31

Thanks for the quick answer, but that did not solve the problem. The MAC GUI still doesn't decode the APE correctly.

Edit: It seems that the WAV created by the MAC GUI lacks a header.

Case

May 2 2004, 10:49

Sorry about the foo_monkey issue. I uploaded new version that decodes correctly with Monkey's GUI and mac.exe.

Sebastian Mares

May 2 2004, 10:54

Yay, it works now!

Moguta

May 2 2004, 12:18

I was hoping for significant improvements, to make APE a more competitive alternative to FLAC. What I've seen so far, the very slightly decreased filesize & slightly increased encode/decode time, doesn't impress me.

According to HansHeijden's graph, FLAC still decodes 2-5x more quickly than APE (12x if you include -insane), while the average difference in WAV compression between the recommended settings is a mere ~4%.

To compare statistics more relevantly, on average a -5 FLAC is ~8% larger, but ~5x quicker to decode & ~2x quicker to encode than an Extra High APE. Against a High APE, -5 FLAC is also ~7% larger, but ~3x quicker to decode & just a bit faster to encode.

For transcoding & playback purposes, FLAC still seems to remain relatively unchallenged. =/

glauco

May 2 2004, 12:29

In the world of lossless codecs, 4%, 5% or 8% means A LOT of diference for many people.

That's the reason for LA to exist.

guruboolez

May 2 2004, 12:29

QUOTE(Moguta @ May 2 2004, 07:18 PM)

For transcoding & playback purposes, FLAC still seems to remain relatively unchallenged. =/

I don't think that flac is advantaged on playback, at least on computer. Except in some rare cases (Pentium 75 or long DSP list, including SSRC in slow mode).
But for decoding purpose, flac is really nice (like wavpack -fast and the unbeatable shorten).
But flac have really poor ratio, and I'm not convinced that MAC have to be considered as a "flac challenger".
The two formats seems to have different purpose or priority.

(EDIT : spelling)

Sebastian Mares

May 2 2004, 13:27

IMHO, Monkey's Audio has a good ballance between compression ratio and speed.

I gave FLAC a try with "Pink Floyd - Hey You" and Monkey's Audio (extra high) converted the 48 MB file to 23 MB, while FLAC (8) reached only 29 MB. I cannot say that the encoding time differed a lot. It took about 7 seconds for MAC and 5 for FLAC on my Pentium 4 (3.06 GHz).

Edit: Spelling

Undesirable

May 2 2004, 15:21

Yes, speed means nothing to me, and I don't understand why it means anything to anyone else really. I do care a little about CPU usage during playback, but APE seems to be fine in this respect; around 4-8%, right in line with WAV. Optimfrog genarally gives me about 2-3 times the CPU usage of APE. I haven't even tried LA because of the Microsoft .NET requirement; there's no way I'm installing that "shizzle."

Anyway, I have a question: I found a plugin for Nero that allows you to burn APEs from CUE files, e.t.c. but it doesn't seem to be working with files encoded in v3.99 of Monkey's Audio. Here's the link:
http://neroplugins.cd-rw.org/

Does anyone know if there'll be an update of this anytime soon, or know of another burning utility that supports CUE + v3.99 APE files directly?

Yaztromo

May 2 2004, 17:07

QUOTE(Sebastian Mares @ May 2 2004, 07:27 PM)

IMHO, Monkey's Audio has a good ballance between compression ratio and speed.

Seconded. I would love to use FLAC, but until FLAC significantly improves compression ratio's the choice is rather mute. I would lose a lot of drive space if I were to re-encode using FLAC, and on todays fast machines Monkey's is quick enough.

fresh540

May 2 2004, 19:32

i'm having trouble converting from normal apes to mp3s via lame 3.96... tried it with an earlier version too, but it still didn't work...

it just crashes and gives me the xp send error dialog. anyone else have this trouble?

mac will transcode to ogg just fine, and decompresses perfectly as well... btw, i'm using the mac gui on windows xp

edit: if i'm on the wrong topic, please let me know where to go

Tec9SD

May 3 2004, 03:58

QUOTE(Undesirable @ May 2 2004, 04:21 PM)

Does anyone know if there'll be an update of this anytime soon, or know of another burning utility that supports CUE + v3.99 APE files directly?

Mausau, the author of the Nero Monkey's Audio plugin appears to have halted releases. The last plugin release was 12/13/03 and several versions behind with some builds (AAC for example).
foobar2000 with the Monkey's Audio decoder (foo_ape) & Audio CD writer components will allow you to do so.

If you're not using foobar, the superb Burrrn by Gambit should, afaik.
Replace the (v. 3.97) MAC.exe within Program Files\Burrrn\ with the new MAC.exe from v.3.99.

Time to sleeep, tec

mahi

May 5 2004, 07:40

QUOTE(p0wder @ Apr 29 2004, 03:44 PM)

I frequently get checksum errors when seeking quickly through ape files at normal compression and above. Fast compression doesn't seem to have this problem though.

QUOTE

ERROR (foo_ape) : invalid checksum

Is this a known problem?

Same problem here - sometimes even during playback. Quite annoying actually. There's nothing wrong with the file itself though.

Sebastian Mares

May 5 2004, 09:30

Seems that the Nero APE plugin is up-to-date now.

eagleray

May 5 2004, 09:47

My problem with this update is that the author chose to break the decoder for a point release with a small increase in compression performance.

Is speed important? That depends. Last night I ran a video reencoding job that took just over seven hours on a P4 2.6ghz machine. Now if I wanted to transcode a bunch of archived albums that day, I would be out of luck.

A lot of the focus around here is on little things. Sometimes too little. Breaking the decoder is orders of magnitude more important than the improvement in compression demonstrated herein.

Jan S.

May 5 2004, 09:49

Why? You can still play old files with the new decoder. 1min to update. That's it.

eagleray

May 5 2004, 12:39

You can play old files with the new decoder, but not the other way around. One minute to update, but only if you know what the problem is and where to get the decoder. Think about it this way, what if varios developers brought out a point upgrades of their MP3 encoders that broke all existing decoders? Havoc would result. Or, look at all the debate about Vorbis 2 and how it will break existing decoders. The exotic and obscure is the norm around here, I sometimes forget.

shnutils

May 5 2004, 15:41

QUOTE(jtclipper @ Apr 30 2004, 01:20 AM)

Still no pipe support for mac.exe, pitty.

I haven't seen any response to this lamentation, so I thought I would mention that I've been maintaining a Windows version with pipe support for use with shntool, available here: http://www.etree.org/shnutils/shntool/

Beware, it's an ugly hack, but it works for me.

jcoalson

May 7 2004, 14:11

added 3.99 to the FLAC comparison

http://flac.sourceforge.net/comparison.html

apple lossless is there too.

Josh

blm07

May 7 2004, 14:33

Ok I'm gonna use 3.99 High compression becuase the Nero plugin now works, and I really like the APE File Info. I like high becuase extra high and insanse save very little space, take longer, and use extra memory to play.

PigsOnTheWing

May 7 2004, 15:12

QUOTE(jcoalson @ May 7 2004, 03:11 PM)

added 3.99 to the FLAC comparison

http://flac.sourceforge.net/comparison.html

apple lossless is there too.

Josh

It's interesting to note that in your test Apple Lossless is so close to FLAC (default) as to not make a difference--414.45 MB vs 413.46 MB--1 MB is certainly nothing to lose sleep over (especially after reading that Microsloth expects everyone to have 1 terabyte of storage to run Longshot--er--Longhorn in '07). This pretty much decides it for me. I had been waiting around until someone had a FLAC or Monkey's Audio solution for Mac OS X (I have both PCs and Macs in my home), but I don't see the point in continuing to wait. It may not have the best compression out there, but as far as I see it, Apple Lossless is the winner for cross-platform support. Nope, it won't work with Linux, but Windows XP and Mac OS X are all that I care about. Apple Lossless is streamable, iTunes runs on both my PCs and Macs (even automatically sharing songs across my network--regardless of whether the machines are running Windows or Mac OS X), I'm even able to play Apple Lossless files on my iPod. I've got ample tags, album covers, smart playlists, the nicest media library interface around...what's not to love? Well, there's no gapless playback right now...but hopefully it's coming. In the mean time, I'll get by with crossfades set to zero, which works fairly well for most transitions.

Regards,

Jay

valiaik

May 7 2004, 17:37

QUOTE(eagleray @ May 5 2004, 07:47 AM)

My problem with this update is that the author chose to break the decoder for a point release with a small increase in compression performance.

The new decoder (v3.99) seems to be decoding v3.97 streams fine, that's ok with me. I tested with Easy CD-DA Extractor, it now includes the latest Monkey.

Mr_Rabid_Teddybear

May 7 2004, 20:42

From my preliminary testing: It's not that different from .96 or .97 - .99 will produce a working gapless file at -c4000 ... anything above will be be buggy and (halfway) unplayable and anything below will be a waste of space unless your CPU is 10 yrs old ...

reardon

May 10 2004, 17:04

QUOTE(Case @ Apr 29 2004, 11:20 AM)

3.99 versions:
Console frontend : http://www.saunalahti.fi/cse/temp/MAC.zip
foobar decoder: http://www.saunalahti.fi/cse/temp/foo_ape.zip
foobar encoder: http://www.saunalahti.fi/cse/temp/foo_monkey.zip

Case: have these been updated for Update 2? I'm still having Unicode problems on my end.

+Reardon

Case

May 10 2004, 22:39

QUOTE(reardon @ May 11 2004, 01:04 AM)

QUOTE(Case @ Apr 29 2004, 11:20 AM)

Case: have these been updated for Update 2? I'm still having Unicode problems on my end.

+Reardon

MAC.exe has not been updated since the initial compile. It's limited to ANSI characters anyway due to the way it was written.
Foobar components are not affected by any Unicode bugs in Monkey's code since they use only I/O functions provided by the player.

Mr_Rabid_Teddybear

May 11 2004, 16:18

Ashland isn't the man that makes info too easily available. There's nothing on the front of home or download page (or in the distribution) that indicates that there's updates within the whole number releases. You'll have to go into the forums and piece it together. This is the changelog for the 3.99 release AFAIK sofar.... More updates might be forthcoming.... (?)

QUOTE

Monkey's Audio 3.99 Update 4

1. Fixed: Decoder could erroneously report a CRC error on the last frame of some files.

(NOTE: SDK also updated)

Monkey's Audio 3.99 Update 3

1. Changed: Worked on making data types more standard / cross-platform friendly.
2. Changed: Switched code from tab-based to space based. (may still be some out-of-whack formatting)
3. Fixed: Building ID3 tags could cause a crash.
4. Fixed: APL builder treated the last part of a CUE time as a hundreth of a second instead of as a frame. (1 / 75 of a second)
5. Fixed: File Info dialog used by Winamp plugin wouldn't accept / save Unicode tag values properly.
6. Fixed: APL files could output noise or silence at the end of the file in some cases.

Monkey's Audio 3.99 Update 2

1. Fixed: Possible buffer overflow attack weakness in APE tagging code.
2. Fixed: MACDll.dll was not doing ANSI to Unicode conversions properly.
3. Changed: Added Unicode versions of interface wrappers to MACDll.dll.
4. Changed: Updated Winamp plugin to better handle Unicode.
5. Changed: Removed peak-level normalize from file and Winamp plugin. (newer players can do normalize / replay gain during playback)
6. Changed: Updated Cool Edit filter to 3.99.

Monkey's Audio 3.99 Update 1

1. Fixed: MACDll.dll wasn't working on Win9x / ME systems.
2. Changed: MAC.exe updated to 3.99.

Monkey's Audio 3.99

1. Changed: Decoding engine better at handling corrupt streams / loss of internet connection while playing.
2. Changed: Simplified assembly code building for 3rd party developers.
3. NEW: Improved entropy coder for increased compression.
4. Changed: Removed RKAU support. (since it is no longer commonly used)

Well, latest version of release always same places:

MAC 3.99F

Monkey's Audio 3.99 SDK (with source code)

radfaraf

May 12 2004, 18:58

QUOTE(Yaztromo @ Apr 29 2004, 12:50 PM)

1. Changed: Decoding engine better at handling corrupt streams / loss of internet connection while playing.

Wondering if anyone tested 3.99 on a corrupt .ape ? In the older version with foobar I would always get long several second screeching sounds on corrupt ones. Does it sound less annoying now ?

I'd test myself but I have all my previously corrupt apes replaced with good ones.

Tec9SD

May 17 2004, 12:34

For those interested,
DCoder has released a DirectShow decoder filter for Monkey's Audio v.3.99.
Win 9x-ME Unicode support (of course Unicode support under NT based OS's) and "Files are no longer restricted to .APE or .MAC".

QUOTE

CHANGES
------------------------------------------------
v0.9
-apl is now parsed by MAC Decoder
-added ApeTags (also parsed by MAC Decoder).
-MAC Decoder updated to v0.99u4

MonkeySource_v0.90.zip Binary
Home: DS Monkey Audio - DirectShow Filesource Decoder Filter

File attributes and listing for anyone who cares:

05/15/2004 04:10 PM 75,264 MACDec.dll
05/15/2004 03:38 PM 4,481 ReadMe.txt
05/15/2004 03:37 PM 181,248 MonkeySource.ax
01/06/2004 07:33 PM 139 register.bat
01/06/2004 07:33 PM 145 unregister.bat
04/21/2003 03:09 PM 245,408 unicows.dll

See ya, tec

Tec9SD

Jun 16 2004, 22:57

For those interested, there is a new MACDll.dll/plug-in for Winamp & Cool Edit from Matt Ashland/Monkey. Thread is here.

QUOTE

Posted by: monkey Posted on: Jun 1st, 2004, 10:09pm
There's an updated MACDll.dll here:
http://www.monkeysaudio.com/files/MACDll_399t2.zip

It works like the old MACDll for the Monkey's Audio front-end and EAC.

However, it is also the Winamp plugin and the Cool Edit filter.

It adds Media Library support to Winamp. It eliminates a bunch of code and streamlines plugin updating. It'll make it possible for the new GUI and plugins to leverage some of the same file info tools.

To use it in Winamp, rename it to in_APE.dll and place it in the Winamp plugins directory.

To use it in CoolEdit, rename it to APE.flt and place in in the CoolEdit plugins directory. (does it work in Adobe Audition ?)

Please let me know how it works for you.

Thanks

ogia

Jun 17 2004, 03:32

QUOTE

I frequently get checksum errors when seeking quickly through ape files at normal compression and above. Fast compression doesn't seem to have this problem though.
QUOTE
ERROR (foo_ape) : invalid checksum
Is this a known problem?

Same problem here - sometimes even during playback. Quite annoying actually. There's nothing wrong with the file itself though.

QUOTE

Monkey's Audio 3.99 Update 4

1. Fixed: Decoder could erroneously report a CRC error on the last frame of some files.

I didn't see answer to these complains.
I've also encountered such invalid checksum error near the end of the song, but not often. The rest of the files from the same album (same encoding) are OK.
The file (song) version is 3.98 with Extra High compression.
I use latest version 0.8.2 from foobar2000.org and in_ape.dll from there.
However file plays fine with older 3.98 plugin.
Seems this is known (and fixed??) bug for Monkey's author, but not for Foobar2000.
But it crashes also in winamp with the above MACDll_399t2 plugin, hence the ??.
Checking ignore bitstream errors, as suggested by the crash message - solves the problem.
At the end -with this plugin 399t2, finally Winamp's library works with ape files reading their tags. Miracle

Case

Jun 17 2004, 09:33

QUOTE(ogia @ Jun 17 2004, 11:32 AM)

I've also encountered such invalid checksum error near the end of the song, but not often. The rest of the files from the same album (same encoding) are OK.
The file (song) version is 3.98 with Extra High compression.
I use latest version 0.8.2 from foobar2000.org

I think the file there is old. Could you try if this version solves the issue.

ogia

Jun 17 2004, 16:27

Hi Case,
This dll is indeed different from the one I use, but the problem persist.
I keep old version of foo_ape.dll (not in_ape.dll, it was mistake in my previous message) which is 114 688 bytes from 24.02.2004 and it should be based on 3.98 (foobar 0.8.2 doesn't list it in the components where version is shown). With it file plays without problem to the end. Both other version based on 3.99 - the new one you gave me and this one, I downloaded today, give

QUOTE

ERROR (foo_ape) : invalid checksum

.
Strange, I checked (played) all 51 files from the same album (encoded with same settings), but no other have this issue.

Beside that, I want to use this chance to express my gratitude to you and of course Peter and other developers.
Now after years of waiting for working library in winamp, the irony is that I don't need it any more. Database functionality of Foobar is much superior. Kudos.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.