I Have Decided To Go With Ape...

Topic: I Have Decided To Go With Ape... (Read 26284 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

I Have Decided To Go With Ape...

Reply #50 – 2003-07-24 20:01:42

Your wish is my command.

This version does not automatically create a backup copy. If you still want a backup, you can use the -b parameter (e.g. "FixAPL -b Test.apl").

Note that the link points to a .zip file this time. It contains both the binary and the source code, if you want to play around with it. The old link (from my previous post) still points to the previous version (just for safety, in case I introduced some horrible bug in the new version ).

Aside from fixing any bugs that might pop up, I don't think I'll do any work on this utility during the next days or weeks. I have been thinking about adding extra features (wildcard support, cue sheet support, ...), but I won't do that anytime soon. Basically, I don't really need them personally, and I don't have that much time to work on it anyway. Other people are of course welcome to further improve the utility.

I Have Decided To Go With Ape...

Reply #51 – 2003-07-24 20:52:54

It is interesting that APL, although a very nice feature, is not taken care of as it should in Monkey's Audio. I doubt the planned support of replaygain for 3.98 would apply to APL files too.

I Have Decided To Go With Ape...

Reply #52 – 2003-07-24 21:03:55

The degree of compression for most good lossless formats if within a few percent so that's also not an important issue.

I don't think that the processing power needed for decoding is an issue. Decoding APE would normally be faster than MP3 VBR.

Storage space is probably the current bottleneck. A 30GB iPod-like device would store around 90 average CD's so storage space is getting close.

I Have Decided To Go With Ape...

Reply #53 – 2003-07-25 20:13:33

Quote

With all these posts about the APL bug and possible fixes, shouldn't we create a separate thread about it ? Or maybe let a moderator split this thread ?

I agree to this. How do you get mods attention? Yooohooo!?

Ok, I already wrote an introduction for the APLfix split thread:

Quote

MakeAPL has a small bug when converting between CD frames (mistaken for 100th's of a second). This has the effect:
- APL files are generated with slightly different start/end points
- Tracks gaps may be noticable in an audible sense
- It is only APL specific with players that use APL files, it does not affect the APE and CUE files in regards to EAC and Nero which can recognize the CUE info correctly.

I Have Decided To Go With Ape...

Reply #54 – 2003-08-13 16:42:34

Quote

Again wrong! By the way it´s called "Extra High", not "Extreme". But besides that, this compression-level offers only a little bit smaller files (maybe around 1 % or less) than in the "High"-mode, but needs lots of more ressources (about 2 to 3 times!!!). With "ressources" I mean processor-time for encoding, decoding and also playback in WinAmp. To make it short, it´s an absolutely bad idea to encode in "Extra High". Believe me: "High" is the right way!

When your encoding a lot of music. That little bit extra space could go along way.

Processor time for on the fly decompression of extra-high encoded monkeys audio isn't an issue at all with modern processors. My XP1800 isnt even stretched to 1% usage on extra-high monkey's files.

If you want to use high compression, you may as well use extra-high. The extra time usage even on compression is negligable.

I Have Decided To Go With Ape...

Reply #55 – 2003-09-04 12:52:44

Quote

Oh, and about command-line usage with multiple files: this command-line works for me:

Code: [Select]
for %a in (*.apl) do FixAPL.exe "%a"
In a batch file, you should use %%a, straight from the command-line you should use %a. Also, don't forget the quotes if the filename contains spaces.

Hi,

some troubles with filenames (Windows98SE).

filebatch's code:
----------------------
for "%%a" in (*.apl) do FixAPL.exe "%%a"
----------------------

filebatch's input: 08-blue_dress.apl
filebatch's output: 08-BLU~3.APL

Thanks for the fixapl tool

urak

I Have Decided To Go With Ape...

Reply #56 – 2003-09-05 20:42:28

Hi

Being a non-techie newbie I'll just ask this simple Q:
Can I now use the FixAPL.exe utility (version without *.bak output) on my *.apl files, and rest assured that the numbers are computed correctly and not give it another thought......?

And, by the way.... does this setup handle non-ASCII characters in filenames, tags and such?

I Have Decided To Go With Ape...

Reply #57 – 2003-09-05 22:16:56

Quote

....
If you want to use high compression, you may as well use extra-high. The extra time usage even on compression is negligable.

Oh boy, what do you say? - If "extra-high" needs about 2times longer in compression than "high", and you have a huge collection, it should be negligable?! - NO way, even with a modern fast processor! - And you should also think about the decompression-time, when you once should need the WAV´s again! It´s always a bad deal to get a gain of about 1 percent only, and to have the double effort for it.

I Have Decided To Go With Ape...

Reply #58 – 2003-09-05 22:56:19

Quote

If you want to use high compression, you may as well use extra-high. The extra time usage even on compression is negligable.

Noooo....it is not negligible...stick with "normal" (-c2000) or at most "high" (-c3000)
your computer will be MUCH happier, so will you...
trust me....I speak from experience...

also, the DEcompression of extra-high (ie playing the files) is just plain horrible in terms of CPU usage...

I Have Decided To Go With Ape...

Reply #59 – 2003-09-08 09:34:43

Quote

also, the DEcompression of extra-high (ie playing the files) is just plain horrible in terms of CPU usage...

That's your opinion. You should allow other people to have different opinions.

My point of view:
APE extra-high files need about 10% CPU for playback on my PC. While that's a lot more than MP3 playback (1% CPU) it still doesn't bother me. Recently I went even further and converted my entire collection of APE files to Lossless Audio (LA) using its -high mode. I saved more than 2 GB hard disk space. Those LA files need about 25-30% CPU for playback which is still fine for me. It's easily realtime, that's all I need...

I Have Decided To Go With Ape...

Reply #60 – 2003-09-08 18:28:13

Quote

Quote
If you want to use high compression, you may as well use extra-high. The extra time usage even on compression is negligable.

Noooo....it is not negligible...stick with "normal" (-c2000) or at most "high" (-c3000)
your computer will be MUCH happier, so will you...
trust me....I speak from experience...

also, the DEcompression of extra-high (ie playing the files) is just plain horrible in terms of CPU usage...

Yes, sorry my mistake. Compression time does increase a fair amount between high and extra high modes. My apologies If you care about compression time and decompression time back to wav file then High or Normal would be better.

But I will disgaree that decompression when playing is horrible in terms of CPU usage. Unless you're running an archaic processor there's no problem at all. On my XP1800 CPU usage sits at 0% and occasionally jumps to 3% (winamp 2.91 and APE 3.97 playing Extra-High files). I can't remember what the CPU usage for my Duron 750 was. But I never had any stutter etc.

I Have Decided To Go With Ape...

Reply #61 – 2003-09-09 20:19:33

Quote

Yes, sorry my mistake. Compression time does increase a fair amount between high and extra high modes. My apologies If you care about compression time and decompression time back to wav file then High or Normal would be better.

But I will disgaree that decompression when playing is horrible in terms of CPU usage. Unless you're running an archaic processor there's no problem at all. On my XP1800 CPU usage sits at 0% and occasionally jumps to 3% (winamp 2.91 and APE 3.97 playing Extra-High files). I can't remember what the CPU usage for my Duron 750 was. But I never had any stutter etc.

That´s right. Playback is not the real problem. But very very often you want to generate out of your lossless files lossy ones (like MPC or MP3 etc.), and then it´s really a pain in the ass when the whole coding-process needs around 2 or 3 times longer, only due to this lousy 1 or 2 % of gain in harddisk-space you had, because you have gone with "extra-high".

I Have Decided To Go With Ape...

Reply #62 – 2003-09-09 21:51:49

I never noticed that difference in encoding an mp3 from an APE extra high and APE high. To be honest, LAME is the real bottleneck, encoding at around 3x realtime, whereas the APE decompresses at more like 20x realtime. Even when creating an OGG or MPC, I find that decoding the extra high APE is by far the quicker of the two processes.

If you're running an old processor (<750mhz) then this shouldn't change, LAME would encode at 1x and APE decode at 5x?

I Have Decided To Go With Ape...

Reply #63 – 2003-09-10 01:36:38

Quote

That's your opinion. You should allow other people to have different opinions.

Did I suggest otherwise? sorry if I did

Well, I admit to having an "archaic" processor, but it does me just fine for most purposes and, with the money it would take to upgrade, I could buy a hell of a lot of disk space....

I've just found that in my experience, Monkey's "sweet spot" is "high" (-c3000). It offers a useful reduction in filesize over "normal" without the performance penalty of "extra-high"

For me, however, the decompression time (ie transcoding to lossy formats) is fairly critical, hence why I tend to go with FLAC and live with the slightly larger filesize....YMMV, obviously (not to mention cross-platform support, "proper" replaygain etc...etc...)

I do admit, however, that size IS important, and I'm quite happy to be persuaded I'm wrong...

I Have Decided To Go With Ape...

Reply #64 – 2003-09-10 12:03:11

Quote

Hi

Being a non-techie newbie I'll just ask this simple Q:
Can I now use the FixAPL.exe utility (version without *.bak output) on my *.apl files, and rest assured that the numbers are computed correctly and not give it another thought......?

Actually, it's not that simple. You have to be a bit careful with it.

You should use this utility only with APL files that are incorrect (i.e. fresh from MakeAPL). If you run it on APL files that are correct (e.g. files that already have been corrected once, or files generated by foo_apl), they will be incorrect again.

This is because the program simply applies a correction factor. It cannot further verify the computed value (the Perl script I based this program on also worked this way).

AFAIK, the only way the program can verify the value is by looking in the original CUE sheet (the one used to generate the APL file). At one point, I actually had plans to add something like that to FixAPL (it would look in the current directory for a CUE sheet, or you would be able to specify one from the command-line), but I didn't do it because:
1. I lost interest. I don't use MakeAPL anymore and so I am not affected by the bug.
2. It's just a simple fix for a bug in MakeAPL, it didn't make sense for me to add all kinds of features. I simply saw the original Perl script and thought "it would be more convenient if it were a native binary" so I rewrote it in C.

Anybody else is still free to add this feature to FixAPL. I included the source code in the ZIP file.

To be honest, I would recommend you (and anyone else) to just stop using MA's MakeAPL (at least until this bug is fixed), and use Foobar2000 with the APL plugin instead. That's what I'm using, and at least this way we know the APL files are always correct (I trust Case ).

Quote

And, by the way.... does this setup handle non-ASCII characters in filenames, tags and such?

The tags should remain untouched (the program only modified the start and end block). I'm not sure about the filenames. I use the standard rename() function, from MinGW's C library. Can you give it a try ?

I Have Decided To Go With Ape...

Reply #65 – 2003-09-10 12:07:22

Quote

Quote
Oh, and about command-line usage with multiple files: this command-line works for me:

Code: [Select]
for %a in (*.apl) do FixAPL.exe "%a"
In a batch file, you should use %%a, straight from the command-line you should use %a. Also, don't forget the quotes if the filename contains spaces.
Hi,

some troubles with filenames (Windows98SE).

filebatch's code:
----------------------
for "%%a" in (*.apl) do FixAPL.exe "%%a"
----------------------

filebatch's input: 08-blue_dress.apl
filebatch's output: 08-BLU~3.APL

Thanks for the fixapl tool

urak

I'll look into it when I have time. I use Windows 2000, but I should still have a Win98SE CD lying around somewhere, and I can run it in a VMWare session.

Can you tell me a bit about this filebatch, though ? I haven't heard of it yet.

I Have Decided To Go With Ape...

Reply #66 – 2003-09-10 13:31:12

Quote

Quote
Quote
Oh, and about command-line usage with multiple files: this command-line works for me:

Code: [Select]
for %a in (*.apl) do FixAPL.exe "%a"
In a batch file, you should use %%a, straight from the command-line you should use %a. Also, don't forget the quotes if the filename contains spaces.
Hi,

some troubles with filenames (Windows98SE).

filebatch's code:
----------------------
for "%%a" in (*.apl) do FixAPL.exe "%%a"
----------------------

filebatch's input: 08-blue_dress.apl
filebatch's output: 08-BLU~3.APL

Thanks for the fixapl tool

urak
I'll look into it when I have time. I use Windows 2000, but I should still have a Win98SE CD lying around somewhere, and I can run it in a VMWare session.

Can you tell me a bit about this filebatch, though ? I haven't heard of it yet.

The trick:

you must put "lfnfor on" command before the for cycle.

@PoisonDan: your tool works very well!

Bye, Rudy®

I Have Decided To Go With Ape...

Reply #67 – 2003-09-11 03:17:23

Thanks for answering me, PoisonDan!

Quote

1. I lost interest. I don't use MakeAPL anymore and so I am not affected by the bug.

Actually, with Foobar and lameAPE with direct cuesheet input, i don't think I need them much more myself, either

Quote

I use the standard rename() function, from MinGW's C library. Can you give it a try ?

Ehhh.... would be delighted to, exept, being a non-techie, i must (embarrassedly) ask: What is that? (I try googleing...) thanks again!

Quote

But I will disgaree that decompression when playing is horrible in terms of CPU usage. Unless you're running an archaic processor there's no problem at all. On my XP1800 CPU usage sits at 0% and occasionally jumps to 3% (winamp 2.91 and APE 3.97 playing Extra-High files). I can't remember what the CPU usage for my Duron 750 was. But I never had any stutter etc.

Being a man not of vast fiscal resources I'm still on an old Pentium III 500 MHz box. I have now gathered the necessary components and will build a new box next week. But now still on a 500 box I did a test of encoders - both lossless and lossy.
As the lossless goes - Monkey's taking a good portion of CPU, yes, but there's still plenty to go on if I don't do too much other stuff simultaneously. And I can not in my best will see much differences in terms of CPU usage in encoding or playback between -c3000 and -c4000. I didn't check to closely for encodingtime, but it wasn't too bad for either. La and OptimFROG, on the other hand, I could not playback AT ALL, and La used 30 minutes to encode a nine and a half minute track! Flac and LPAC goes most gently on the CPU, Wavpack is the fastest, uses a tad bit more CPU on playback than Monkey, but all, except La and OptimFROG, are fully playable. LPAC a bit slow in encoding, maybe.

I Have Decided To Go With Ape...

Reply #68 – 2003-09-11 06:56:59

Quote

The trick:

you must put "lfnfor on" command before the for cycle.

@PoisonDan: your tool works very well!

Bye, Rudy®

WOW! It worked perfectly for me (w00t)

Manymanymany thanks!

I Have Decided To Go With Ape...

Reply #69 – 2003-09-11 07:25:40

Quote

Quote
I see more and more people going the lossless route. There's gotta be some hardware support. (I'm familiar with the MusicKeg and so on, but i'm talking about something portable, like the iPod)

The problem with most lossless codecs though, Ape included I think, is that they require too much cpu time to decode. I don't think you'll be seeing a portable very soon with the required horsepower to handle this stuff in realtime. Not only that, but there's memory usage issues and other embedded platform oriented problems to consider for which Ape may not be ideal at all. FLAC and some more commercial formats are a little different than the rest in that they have been designed from the start with these points in mind, but even then there still isn't much support for them compared to lossy formats.

If I may interject something concerning CPU overhead requirements of decoding lossless (as well as lossy), and to share some specific experiences...

I have done extensive testing of both FLAC and Vorbis decoding on the PhatNoise/Kenwood Music Keg, which is equipped with a 74MHz ARM processor and 32MB of onboard RAM. I used FLAC on it exclusively for over a month, with extensive listening time (well over 100 hours). I played at least 300 songs in FLAC 1.1.0 format on it (from a variety of genres), and I never once experienced a skip or any apparent buffering problem frequently evident with codecs pushing the "hardware limits" upon decoding. For reference, my FLAC encoding command line was:

flac.exe -8 -m -l 16 -r 8

By comparison, I most recently tested Vorbis on the Music Keg, using both Post 1.0 CVS and GT3b1 encoders at quality levels between 3.00 and 10.00. I found that the maximum quality level all tracks I tested (approximately twenty initially, and over 100 since) could play back without skipping was -q 4.25 with Post 1.0 CVS, and -q 4.1 with GT3b1. Any higher of a -q setting, and some samples (with higher bitrate peaks) would skip as buffer underruns would occur. So by these tests (though on only one hardware platform), FLAC would seem to have even a more tolerant hardware requirement than Vorbis when using limited CPU and memory.

Specifically regarding possible future hardware support for Monkey's Audio... I believe that codec portability (helped by being open source) and low-hardware overhead reqs results in more hardware support more than selection because of perceived popularity. I don't know why PhatNoise chose FLAC over any other compressed lossless format (so far), but it could have been because of reasonable minimum hardware requirements combined with being open source. I'm not aware of PhatNoise customizing a FLAC decoder for their platform, but I do know they modified a version of the Tremor (integer-based) decoder libs for Vorbis, made possible by being open source and patent-free (BSD license).

I don't know whether Monkey's is open source, but if it's not, this could represent a block for future hardware support for it. If it is, someone should try to make a version of an APE decoder that can run with less CPU and memory to prevent
buffer underrun in realtime, as well as any other decoder issues. After doing this (if successful), people should lobby hardware manufacturers to use APE. That's the only way I could foresee portable/car player support for the format.

I Have Decided To Go With Ape...

Reply #70 – 2003-09-11 08:29:18

Quote

I don't know whether Monkey's is open source

This is from Matthew T. Ashland's site:

Quote

Freely available source code, simple SDK and non-restrictive licensing - other developers can easily use Monkey's Audio in their own programs -- and there are no evil restrictive licensing agreements

Quote

The evil legal stuff:

Just to be clear, you'll have to agree and comply to all of the terms of the license agreement (included with a full download) to use Monkey's Audio in your own product. Basically that means that if you're a freeware author, go nuts. If you're trying to make money, in any way, talk to me first. I probably won't care at all if you just use MAC, but I might. Anyway, read the full license agreement and contact me if you do anything with this SDK.

http://www.monkeysaudio.com/developers.html

I Have Decided To Go With Ape...

Reply #71 – 2003-09-11 19:43:10

It is not legal to redistribute (at least in the US) the Monkey's Audio SDK (or anything linked to it) under its current license because parts of it are GPL encumbered.

What the hardware guys need:

0. a good reason to support the codec in the first place (of course)
1. no legal encumberences
2. no license fees (only MPEG and possibly M$ can command them)
3. stable, portable, efficient reference implementation suitable for hardware
4. stable, well-documented API suitable for embedding

Hardware makers suffer enormous discomfort and often financial losses when any one of these fail. And doing them all right is not as easy as it sounds. Having done both embedded design and chip design I already knew what to aim for with FLAC. Most other codecs aim for a Windows implementation on a fast x86; they are fundamentally incompatible in several ways for use in consumer gear. I think the only other lossless codec that really has a chance in hardware is WavPack 4, since it is going through a redesign by a guy (Bryant) with a hardware background also.

Josh

I Have Decided To Go With Ape...

Reply #72 – 2003-09-12 14:39:37

Quote

I never noticed that difference in encoding an mp3 from an APE extra high and APE high. To be honest, LAME is the real bottleneck, encoding at around 3x realtime, whereas the APE decompresses at more like 20x realtime. Even when creating an OGG or MPC, I find that decoding the extra high APE is by far the quicker of the two processes.

If you're running an old processor (<750mhz) then this shouldn't change, LAME would encode at 1x and APE decode at 5x?

But but but..... if encoding is slow, automatically decoding and playback also. That´s a law of nature in codecs. Because playback (and transcoding from APE->MP3 e.g.) does that all only in smaller portions.

So, I made a quick test to proof my claims. I compressed the album:
Nick Cave & The Bad Seeds - The Boatman's Call
Total filesize in High-Mode: 255 MB (rounded)
Total filesize in Extra High-Mode: 253 MB (rounded)
Gain: 2 MB ~ 1,1 % - .... that is negligibly !

Total time needed for decoding:
Extra high-mode: 3:15 mins. = 195 secs.
High-mode: 1:56 mins. = 116 secs.
More time-effort: 79 secs. ~ 68 % more to decode needed. - And that´s for sure not negligibly !

I hope these datas do clear up all now. So, definitely: Using....
... High = GOOD idea (same with Fast and Standard)
... Extra-high = BAD idea (same with Insane)

I Have Decided To Go With Ape...

Reply #73 – 2003-09-12 14:48:49

As long as there are always space constraints, there will be people who need that extra compression for their files, over and above the priority for fast file decoding. It would be naive to dismiss this necessary demand of this niche of audiophiles.

I've read about asymmetric codecs. Is there a limit to making decoding as fast as possible, independent of encoding speed?

Anyway, R.A.F, the point that Mac was making was that, regardless of processor speed, LAME mp3 encoding (especially with the VBR presets) will always be slower than the decoding of APE files in Extra High mode.

I Have Decided To Go With Ape...

Reply #74 – 2003-09-12 14:53:59

But, excuse me, we are talking about a gain of only about 1 percent ! - And finally we live in the 250 GB-harddisk-age. From next year on maybe even in the 320 GB... No, sorry, an argumentation like that moves behind my horizon.

P.S.:
Sorry for my bad english. I like this expression anyway, even if it doesn´t exist in english.

Notice