Afer a lot of thought about the future of my digital audio collection I've settled on Ape with Extreme High Compression.

At first i was going to go the LAME --alt-preset extreme route, but the more i thought about it, I probably won't be happy with the quality in a few years. So, reading posts on this board finally convinced me.

Why Ape?

• I'm not concerned with inter-OS compatibilty.
• It offers the Highest Compression.
• Lossless is Lossless is Lossless -- I can always convert to a better format later.
• Some people don't go with Ape because of lack of hardware support -- I think it's just around the corner. If there isn't a lot of support for Ape in the furture, again, I can always convert.

EDIT: I'm using MAC 3.97, is that the best version available?

I'm using EAC for ripping, and the command line utility (MAC.exe) so I can automatically have it compress after ripping. Is there anything else I need to know? (Command line switches I should use, any other utilities i need to be aware of before I start ripping that would makes the process easier, etc.) Also a handy utility for helping me with tagging would be nice.

Oh, yeah.. The way i do the math it'll take about 5 or 6 200gig drives to rip my collection. And i'm a paranoid bastard, so I keep offsite copies of almost everything. So I'm going to need about 12 200 gig drives total.

Anyone know any good deals?

Thanks!

I'd help you if you agree to send me all your archive in a flourescent media when they become popular



I guess LA and OptimFrog offer better compression.



I guess with around the corner, you mean 10 years ahead. The average consumer couldn't care less about lossless.



3.98 is around the corner. Alpha version is released. I don't think it offers much in terms of compression but use of APEv2 tags are important.

Doesn't EAC tag automatically? If I were you I would not extract track by track but get an entire image extraction and use APL files to access individual tracks. And also do not forget to extract CUE sheets. You'll also need them for MakeAPL software.

What's APL, and why not track by track?



It does, but I think it only tags automatically with ID3 v1.1 tags. Am I wrong?



Why?

Because it seems more logical a choice to me. It also preserves the gaps automatically. This way, you'll have a single image file: CDImage.wav to be encoded into CDImage.ape. To access the individual tracks you'll be using APL files. Consider them as bookmarks to your tracks in the file. Try the MakeAPL software. It is in the same folder with Monkey's Audio.



Don't know and haven't tried that really. You might use Tag to batch retag them into APEv2. Doesn't Tag support Monkey's Audio files? Oh there you go. That's another reason for using APL files. You won't have individual tracks to bother with tagging. They're extracted from CUE sheet information into APL files by MakeAPL.



Because APEv2 tags are better designed and recommended over APE tags. I can't find the link right now. You need APE tag spec page in Frank Klemm's site somewhere.

No, use mac.exe version 3.96b7 by Frank Klemm (pipe enabled e well tested) and use preset -c4000 (-c5000 and -c6000 are experimental).

Use EAC with wapet (by Case) for direct Apev2 (better tags) tagging:
wapet (http://www.saunalahti.fi/~cse/files/wapet.zip)
guide: http://www.saunalahti.fi/~cse/EAC/index.html

Remember: current makeApl is buggy; the problem is how to treat the under second field in cue sheet. The field represents frame number, so it is from 0 to 74. However, Makeapl calculates is as 1/100 second.
You must use a perl code by Alpha-S.I.D. or compile by Destroid:
http://www.geocities.com/feedthedead/apl_f...fix_mod_bin.zip

More info on monkey'audio forum (http://www.monkeysaudio.com/cgi-bin/YaBB/YaBB.cgi?board=general), check these threads:

"Differ point between apl and splitted wave"
"Monkey's Audio 3.98a1 available"
"Updated pre-alpha-GUI available"

Don't use 3.98 (ALPHA), very buggy.

Bye, dB

Shoot, the APL fix link is not working. Can anyone post another link? I use APL stuff quite often...

what is pipe enabled? and what does the -c4000 switch do?

What gives you this impression?

I seriously doubt this is going to be happening anytime soon, if ever.

Well, I also said:



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 they advertise 64kbps WMA as CD quality, I don't know how they'd advertise lossless Indeed, I don't think any of these companies would include lossless support soon. Because lossless is an overkill for your portable. Those devices are not designed usually for extreme high end quality (included DAC, SNR wise). If you have such a huge archive, going the MPC route might save you more than a grand.

Wait a sec, wasn't there an Ogg FLAC support controversy for iRiver or was it some other company?

Well, I never thought of it that way, but it does take a lot more to process lossless music. Something a small portable player can't provide.

I demand portability, I can't just sit in front of my comupter for music. I'm always on the go. Maybe I jumped the gun on this one..

I'll probably go back to mp3 -- a tried and true standard. Maybe MPC.. we'll see. I gotta sit on this one.

Well if so. Monkey's Audio is not a good choice to begin with. If any lossless format would ever get support, the chance of it being Monkey's Audio is slim.



Come on those nice 200GB drives would fit in your backpack

He would be the modern equivalent of Obelix

Rumblings are that the Rio Pearl will do FLAC and Vorbis.

I have a feeling if enough people asked, the Neuros guys would do FLAC too. It would be great for tapers. I've offered to help.

Practically speaking, the only thing that has a chance on any portable is FLAC, WMA lossless (yuck) and maybe WavPack 4.

Josh

Based on current industry trends, I'd probably go with a relatively high bitrate mp4/aac if you demand portability. Portable support is already here and codecs are improving rapidly.

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!
Good, to have asked us before....
P.S.:
I have myself also around 100 DVD-R´s burned with APE´s. So.... I must be right.


And to the other formats: To MPC belongs my heart. But to be realistic, I would go for MP3. But again: Why for "alt-preset extreme"? - "Alt-preset standard" is already good enough for 99,9999 % of your musics. Especially if you plan to play them in a portable player, where space is always rare.

Maybe you need to go to the webpage to get??

I believe the APL computation bug will be fixed in v3.98 final, but don't quote me on that.

FLAC is a lossless codec that might get the benefit of portable hardware someday (the 1+ year time-scale?)

If portability is a must, I don't see any reason for choosing MPC despite it's increased quality, as the chances of it getting hardware support are similar to APE/FLAC..

As was suggested, MP4 might offer the compromise for you, higher quality than mp3, but also gaining hardware support and mainstream acceptance

Another option is to continue with your APE backup to harddisks, then use those to encode mp3's for portable play - it takes more space, but you get the best of both worlds


1% of 2400GB is enough to make that worthwhile, unless Dr. M is running his arrays on early 90's equipment.

Thanks for the replies

I'm still doing some research. I need to sit on it a little more. I may end up going with FLAC, or good ole' mp3. Or I may do as Mac suggested, and go with the best of both world's.

Okay, I've been doing a lot of research and the Neuros Audio Player may soon have FLAC support.

That alone is convincing enough for me to go with FLAC.

The information on FLAC is spread and somewhat difficult to find on the forum. Are there any utilities I should be aware of if I use FLAC? What switches do you people use in FLAC?

Also, is there a system similar to the APL files with FLAC? I've been playing with them in MAC and decided i like that system a lot -- it is just good sense to have one large file and a cue sheet.

EDIT:By the way, what exactly is Foobar2000? I can't seem to find any information on exactly what it is.

No. FLAC doesn't have it. You can find that discussion in a recent thread if you do a search. The developer said it's easy to implement but no one got around to it. I guess fb2k player can do it if you have the cue sheet.

Neuros player is bulky. Lossless is lossless, you can always convert it to another format of your choice. But if I were you I wouldn't count on portable support...

Maybe WMA will see portable support in the future. (except for the fact most people here don't like WMA)

Foobar2000 is a software audio player which many around here prefer over others (like Winamp, XMplay, Sonique, 1by1 etc), considering its support for the latest technical achievements in the audio field. I'm sure you'll find plenty of info through its forum that is hosted by Hydrogenaudio and its site.

Hmm, well in that case, I'll stick with MAC.

No one answered my other question:

APL isn't limited to Monkey's Audio format, foobar2000 can use APL files with flacs if foo_apl is installed. Same component can also create APL files from CUEs/FLACs with CUEs.

A pipe (|) enables the output of one process to be directly fed to the input of another process. In this case, the decoding of an ape file can be fed directly to the encoding of the ogg file without having to create a wav file between the decode and encode steps. This only works if the two programs support "stdout" and "stdin" ("standard out" and "standard in"). The original MAC.exe does not. You have to use a modified version that does. You can get one here:
http://rarewares.hydrogenaudio.org/ogg.html
Look for "Lossless Codecs".
You'll also have to use "Oggenc2.2.exe", as oggenc does not support "stdout" and "stdin" either. "Oggenc2.2.exe" is available on the same page as the "Lossless Codecs".


An explanation of "-c4000" can be found in the help from MAC.exe:

"--- Monkey's Audio Console Front End (v3.97) © Matthew T. Ashland ---
Proper Usage: [EXE] [Input File] [Output File] [Mode]

Modes:
Compress (fast): -c1000
Compress (normal): -c2000
Compress (high): -c3000
Compress (extra high): -c4000
Decompress: -d
Verify: -v
Convert: -nXXXX

Examples:
Compress: mac.exe "Metallica - One.wav" "Metallica - One.ape" -c2000
Decompress: mac.exe "Metallica - One.ape" "Metallica - One.wav" -d
Decompress: mac.exe "Metallica - One.ape" - -d (to stdout)
Verify: mac.exe "Metallica - One.ape" -v
(note: int filenames must be put inside of quotations.)"

It tells the Monkey's Audio encoder to encode to the highest compression.

If anybody still needs the Perl script to fix their APL files, you can find the script here (this is a straight copy-and-paste from the Monkey's Audio forum, with the strange characters removed).

For those of you that don't have Perl installed, I created a very quick-and-dirty Windows binary. Since I use the Cygwin version of Perl instead of the ActiveState package, I've also included the necessary Cygwin DLLs.

You can download the binary package here. If anybody of you has the ActiveState Perl package, can you please use Perl2Exe from that package, and post the resulting binary (that won't require extra DLLs) ?

WARNING: I have not tested this script/binary at all. So use it at your own risk. I'm unable to test it right now. I would like to hear if it works or not, though...

w00t, my 100th post!

It doesn't work for me PoisonDan. When I do FixAPL "A.apl" it says "Not found file [A.apl". When I do FixAPL *.apl it only fixes one of the apl files in the directory. I'd appreciate if someone solves this APL thing for me

Isn't this bug fixed in the latest stable or unstable build of Monkey's ? That's so annoying...

I re-uploaded the compile with the modification I made where fixed APL files overwrite old ones.
This should be working, as reported by others. ZIP contains one EXE, syntax is: APL_FIX_MOD.EXE filename.apl
http://www.geocities.com/feedthedead/apl_f...fix_mod_bin.zip

When I tested 3.98alpha still computes incorrect frames.

Thanks a lot! Can we use it with *.APL ?

Um, no. For that you would type:

for %%a in (*.apl) do apl_fix_mod %%a

edit: What works even better is adding (i.e.) "Fix APL" to Explorer File Types, at least then you can avoid many two-second delays since it will open multiple instances at once if many files are selected. However, if you choose this way be aware that 'fixing' APL files twice will result in incorrect tracks.

One second this doesn't work:


I get:

Do I need to create a batch file?

Yeah, but try this instead:

Explorer: View > Folder options > File types
APL (for me, hidden under Winamp media file): Edit > New > Action: Fix APL > Application used... (browse for APL_FIX_MOD.EXE) and at the end type a space and: "%1" (with quote marks).
Click OK. Use by selecting APL files, right-click "Fix APL" and watch the fun.

Hmm that's no good in general though APL should be associated to my player. Could you tell me what I need to do otherwise? Sorry

Edit: Oops sorry, I guess what you suggested does not change the default assoication. Thx.

Edit 2: Can't do it. When I use it in command line it works fine (except for the annoying 2 second delay problem) otherwise, when I add a new action and invoke it the files are not even modified(Yes I added the "%1" at end of the line). It works when I invoke the action individually, but not together.

Well, I don't know if it should work with the Perl script, but on my system it does work with this executable.



Heh. I couldn't resist. I created an APL fix utility, written in C. The most important change right now is of course the size (22 KB!) and speed of the binary. However, if I find the time, I'll add some extra features. Stay tuned.

Anyway, I have also created an extra action for my APL files, using the method Destroid described. I can confirm that it definately does work for me when selecting multiple APL files. If it still doesn't work for you, contact me and I'll try to work it out.

Of course, if you find any bugs in my program, please let me know as well.

Right now, the program always creates a backup copy of the APL file (with .bak extension), but deleting all .bak files afterwards is of course trivial. I haven't implemented any command-line options yet, but I plan to add an option to skip creating the backup file.

I don't provide the source code yet. I first want to implement the extra "features" I've mentioned above.

Have fun.

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



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.

My server just died, but once I get it up and running again, I'll give your app a try - got about 7000 apl files for it to work on

I never liked that pl2exe compile but it was cool a solution existed in Perl.

And thanks for confirming that I am not the only one that got the explorer association part to work.

If you don't backup your APL you can get them back from running MakeAPL again.

As for bugs...

(sorry if I'm too nosy)

Did you find these strings while searching through the executable (as in, being "nosy"), or did you really get these errors while executing the program (as in, "bugs") ?

If the latter is true, I'd like to know more.

It screws up some of the APL files. I'll post an example here (Miles Davis - Tutu track 8, WinAMP APE plugin gives corrupted original file whereas it's not). But the perl2Exe binary created corrupted APL files sometimes that crashed my WinAmp (Kitaro - Dream, track 6). The APL file of the same track for this fix does not crash WinAmp but WinAmp cannot show the length of the track. I can post the cue sheet and the APL files. Non-fixed APL files perfectly work with WinAmp for these examples, but of course they don't correspond to correct positions because of the original bug. Here's the cue sheets for Miles Davis - Tutu and Kitaro - Dream. apl_fix_mod.exe (previously posted perl2exe solution) is also there.

Jus' peekin', I am always tempted to examine small EXE's

As for the crashing, the last "track" on the APE file should have -1 for EOF, not 0.

New version uploaded. Get it here.

Changes:
- Changing -1 for EOF to 0 fixed. (thanks Destroid)
- Better handling of pathnames. ("Shoot the developer" removed )

atici,

Since track 8 is the last track from the Miles Davis album, the bug with the EOF could have caused the problem. Can you check if the new version fixes this ?

However, I have no explanation why track 6 from the Kitaro album causes problems. I created the APL files, applied my fix, compared the changes and didn't see anything wrong with the fixed APL file. I can't play it of course, because I don't have the APE file.

If you still have this problem with the new version, can you post the two APL files for this track ? The original one from MakeAPL, and the one you got after using my utility ?

Thanks for the feedback so far.


Edit: 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 ?

That FixAPL program has some problems, it gave me weird error messages with some filenames:

[E:\Temp\ATTHEG~1]fixapl "At The Gates - Slaughter Of The Soul - 03 - Cold.apl"
Cannot open At The Gates - Slaughter Of The Soul - 03 - Cold.aplndir?.new for writing.

[E:\Temp\ATTHEG~1]fixapl "At The Gates - Slaughter Of The Soul - 09 - Nausea.apl"
Cannot open At The Gates - Slaughter Of The Soul - 09 - Nausea.aplndir=C:\WINDOWS.new for writing.

[E:\Temp\ATTHEG~1]fixapl "At The Gates - Slaughter Of The Soul - 10 - Need.apl"
Cannot open At The Gates - Slaughter Of The Soul - 10 - Need.aplndir?.new for writing.

And it has rounding problems, if you add 0.5 to the new block number before converting to integer you should get correct values.

Yes, I already noticed something similar after some more tests. I think I know what the problem is, I'll get a fix out ASAP.

(The behaviour of some function seems "inconsistent", though. Long story.)

About the rounding problems: can you give me an example ? I already add 0.5 before casting to int, so that can't be the problem. I did notice that MakeAPL itself has rounding problems (i.e. it truncates instead). When I apply the fix, I round the value properly, but because of the problem with the original value there is often still a difference of 1 sample between the resulting value and the value it should be (i.e. the value I get when I manually calculate it from the original cue sheet). This is a problem of Matt's MakeAPL, not my FixAPL. Since my utility doesn't read the cue sheet (yet), it can't verify if the resulting offset is sample-correct.

However, if there still remains another rounding problem in my utility, I'd like to know it (please provide values).

That explains it, I didn't compare the values to MakeAPL's values but to my own APL writer's values. You can fix the rounding problem caused by MakeAPL by rounding to closest multiple of 588 samples, all CD tracks must have such length.

New version uploaded. Same URL.

Changes:
- Fix weird output pathnames.
- Rounds offset number to nearest sector (multiple of 588 samples).

Thank you, Case.

Seems to work perfectly now.


No problem

The latest version seems to solve both my problems. Thanks a lot! I think the next version should not create .bak backups anymore, you can always create the erroneous ones through MakeAPL anyway, and this version seems no longer at beta stage