Been there for weeks.


Cool Edit API doesn't allow using longer extensions and I don't want to use hacks to overcome it.


It is safe to use but don't expect seeing version number 1.0 until I am absolutely happy with it.

Flac, due to speed.
And LA, when I need only compression level - to transmit over internet.

It would take a second longer...

MonkeyAudio.
I was seduce by some FLAC properties (as its claimed robustness), but I had some problems with 1.1 version : problems with Winamp Plug-in, unreadable tags (all corrected now I think).
But most annoying thing was space, for archiving on CD-R. I listen to classical music, and ratio are really high (average 2/5). Therefore, I can archive two and sometimes three CD's into one CD-R. With APE -high, I have many cases were encoding perfectly match the 720 MB, with a little space for covers and notices. With FLAC ratio, it isn't possible anymore (count ~30-40MB difference).
Monkey format is using APEv1 and now APEv2 tag format. I often reencode some APE file to MPC, and tag are properly reported with all GUI I had (exemple : musedrop). I must admit that now, there are some problems with fb2k and 3.98 tagging system (APEv2), and tags are not recognized by mppenc.exe. Nevertheless, fb2k is a very good reencoder, and I'm now using it for tagging/reencoding

I rip directly to wave and compress later.. I err on the side of caution, letting the computer rip while I'm not doing anything demanding, so I didn't like the idea of double-encoding on the fly!


I did a quick and dirty test of LA vs. APE when compiling all the samples for a song of mine to archive. LA ended up 2mb bigger on 35mb of samples. That was enough to make me think it's not worth it..

Also, I didn't like the amount of pressure it puts on decoding, when I'm doing something heavy duty, I find APE will only skip when changing tracks (the same as with OGG) whereas LA just got destroyed under heavy CPU usage, so the trade-off for that extra 1% (or -6%..) wasn't worth it.



To Case:
Thanks for quashing my misconceptions, the last version I tried (a month or 2 ago) didn't work as I wanted, so my guess is I was dumb and picked up your first copy again

My opinion: Encoding speed doesn't matter at all, I usally encode (losslessly) only once. Decoding speed is not very important for me, my PC is the only planned playback device for the archived files. If this should change in the future I will simply transcode my files to the new file format of choice.

The extra compression of APE was the main reason why I'm not using FLAC now. I am aware that there are some codecs that can compress even better. I have yet to find out if LA or OptimFROG meet my requirements for software support:
-playback (Winamp2 support including Albumlist plugin and tagging)
-transcoding (to MP3 for my portable player)
With my APE-archived CD collection I can do that easily. If one of the higher-compressing codecs offers the same usability features then I will change, just to save a few more gigabytes of hard disk space.

Kind of offtopic but decided to ask anyway, is the embedded cue sheet really so stripped that there are no PERFORMER or TITLE fields stored? If it is, I would highly suggest to add these as soon as possible.
For foobar2000 0.7 beta users, here's a FLAC decoder with initial embedded cue sheet support.

I use FLAC. For no particular reason though - it's the first I tried, I've got used to it, and I like it. (Features like native ReplayGain support aren't really relevant for me since I use lossless only for archival, but if I actually started using it for playback, that would be an added bonus.)

I'm a little weary of Monkey's Audio since there have been issues reported of MAC files encoded by an old encoder not being decodable with a recent decoder. I really like WavPack though, both for its encoding speed (whoa!) and for the hybrid concept. If for some reason I was forced to use it instead of FLAC, I'd have no problems doing so.

Appears so, yes :/

There is some reserved space they should fit in, though; failing that, a custom metadata block can be defined to provide more complete cuesheet support, or you could even dump the entire cuesheet in a Vorbis comment like we currently do with ReplayGain (much to the disdain of the spec writers).

Irritating oversight...

Hehe, stick to using this years encoder and there's no problems

I know this seems annoying, but it's on purpose, and here's why.

The cue sheet was originally for laying out the disc, essentially specifying the contents of the TOC. Later CD-TEXT was added. But CD-TEXT is a very complex spec, and actually goes in the CD subcode data. The TITLE/PERFORMER/etc tags are just shorthand for authoring, but when you rip, you almost never parse the CD-TEXT, you get it from another database, and I didn't see any reason why this subset of CD-TEXT should go in the FLAC CUESHEET block.

My intention was the apps could calculate the CDDB or CDindex ID from the CUESHEET block and look it up in an online or local database just like CD players do. But if you really want it in the file itself, the track metadata really should be stored separate from the CUESHEET, and already can be because of FLAC's metadata system. I just didn't specify one because I know as soon as I do, people will say that it's not flexible enough. That is the big problem with metadata and is why Xiph has deferred on it, waiting for someone to come up with a good metadata spec that can me muxed together with data.

Someone has already proposed just storing the CDDB records as Vorbis comments. Then it is a simple matter for the player to parse and use them. I haven't made this official because it is counter to the Xiph comment spec, but someone could spec a separate metadata block for it.

Josh

edit: here's some other threads where it is discussed more:
http://www.hydrogenaudio.org/forums/index....ac,and,cuesheet
http://www.hydrogenaudio.org/forums/index....ac,and,cuesheet

Well, I personally don't like external CD databases on internet, the info in them is rarely typo free or correct. And storing artist/title tag for several tracks in vorbis comments doesn't work nicely either. I find it weird that something as rarely needed information as ISRC code is stored but more useful info is left out

But I think most players support a local database, so you could make corrections.

The proposal was to actually store CDDB key/value pairs like:



Finally, my experience is that anyone who is going to the trouble of keeping a lossless collection in the first place will already be picky about metadata, and it will be really hard to come up with a standard that will please even the majority. If I have an epiphany or someone comes up with a good solution I'll be happy to add it. But there are so many tools for reading and manipulating CDDB databases that it seems like that is a good common ground.

Josh

Has anyone else tried Lossless Audio?? http://www.lossless-audio.com
It compress better than monkeys audio but its alot slower

i second that

Yeah, I just decided to test this before I read your post. I was on a PIII 550, but I just recently upgraded to 1.4 GHz, and I have a new computer at 3 GHz. With the extraction speeds I get in EAC, I'm good with FLAC now, but before I wasn't. Good point!

Flac is supposed to be coming at some point for Neuros.. for record and playback.

I prefer FLAC for my lossless stuff only because of *compatibility*. (Translation: My Phatbox can play it )

Monkey's is a great format too, IMO, with often a little better compression ratio but a little slower compression/decompression algorithm (but on a P4-2GHz, there's little difference I could detect).

My settings are:

flac --best -m -l 16 -r 8

I like both, have both installed, but I do use Monkey's more. And I don't use either that much anyway.

Later.

FLAC

Faster seeking...

FLAC
Fast (yes, this is important to me),
some hardware support, portability, resilience...

I use Monkey's Audio. For me, the real concern is playback. I haven't found a program that has as good a combination of sound quality and ease of use as MediaJukebox/MediaCenter.

I find that other programs are great with smaller libraries, but once my library got above 3000 songs, it was difficult to manage with anything else.

kiwi

I use Monkey's Audio with Foobar2k. Excellent compression, extremely fast seeking, and the little monkey face is the icing on the cake!

Would anyone hazard to guess as to why APEs seek much faster than MP3s with Foobar2k?

APE -extra high .... - -"

FLAC. For four reasons:
1. Works perfectly in my dual OS setup (WinXP + Gentoo Linux), plays in Winamp, Foobar and XMMS.
2. In the future I plan on making a streamable sound server with support for lossy and lossless, depending on listening situation/location.
3. Fast encoding/decoding/searching.
4. A damn good "feeling" that the format is completely free.

And on top of it - now it's finally possible to index the FLAC files with MAC! Thanks!

I have no need for Replaygain or a few extra megabyte extra compression as in Monkey's.

All FLAC files are stored along with PAR2 parity data.

I still use Monkey's Audio, 'cause sometimes I need the extra space to store 2 or even 3 albuns on one CD-R, like guruboolez said. Once I get a DVD+R burner I'll stop using APE completely. But I think it's still the most used lossless format, although this poll may indicate otherwise. At least that's my experience. I wish that FLAC could improve its average compression ratio a bit, without losing its main virtues, which are speed, hardware support (besides being OSS). I know it's easier said than done, though...

cya

depends on the application

flac is clearly the preferred format for sharing live music.

ape is used for pirating studio albums, but other than that it seems to be the choice mostly for those looking to do archiving and backup

shn is still the most widely used lossless format, by far

I use Monkey's Audio for storing all music on my PC.

- Even though FLAC is faster, Monkey's seems damn quick on my XP1800. (a lot faster than lame btw) Decompression while listening doesn't even use 1% of my CPU, so thats not a problem.

- Monkey's compression is better. The amount of albums I have stored with Monkey's now takes up a lot of gigs, but with FLAC I imagine it would take up a lot more.

- The Monkey's GUI is ace, dead simple to use and integrates with explorer nicely

Using APE extra-high is nonsense. Generates only 1 % shorter files than in high-mode, but needs about 70 % more (processor-)time to compress/decompress and play. So, everything is OK: fast, normal, high. All above (extra-high, insane) not. High seems to be the "golden middle", which I use.

Relax! Why are you trying to convince people to use YOUR favourite settings?
The higher CPU usage during playback (just 2 to 5% on modern PCs) is probably irrelevant for most people. So why not squeeze the last bit of compression out of it? Remember, it's still LOSSLESS.

Btw. while we're talking about CPU usage: I'm using La.

It's not just RAF's favourite / non favourite settings. I'd say most people don't even know or care to know what other impacts the highest setting has. And it isn't "just 2 to 5% on modern PCs" all that matters. That is just normal playback. Try seeking. If my P4 can't seek 5 or 10 seconds forward/backward right away with APE extra high (cpu goes to 100% for a few moments), then that tiny little difference in size is useless.

I use MAC because it has a DLL that allows direct ripping to APE in EAC including APEv2 tagging in the 3.98a version (yes alpha but it never caused probs for me).

Haven't found this for Flac yet. Anybody knows wether it exists or not? Or is on the roadmap?

Not sure why support has to be in DLL form when you can just use an external encoder or MAREO... but, there is a DLL for libFLAC (has been for a while) and there is no problem linking against it under the Xiph license. Try pinging the author for support.

Josh

You could try to write this on the command line option:

-V -8 -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s

Or for compression level 5

-V -5 -T "artist=%a" -T "title=%t" -T "album=%g" -T "date=%y" -T "tracknumber=%n" -T "genre=%m" %s

And It'll automatically add tags to your ripped flac files, don't know if this is what you're looking for but It tags your files.