APE vs FLAC

Topic: APE vs FLAC (Read 53192 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.

Reply #50 – 2003-07-03 06:13:45

Quote

I found the FLAC filter for CoolEd was missing things like setting the compression level

Been there for weeks.

Quote

, it saves .fla rather than .flac

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

Quote

I don't trust it until it is labelled as totally safe, I remember the first test giving anomalous file-sizes and it was only furthered by 1 build..

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

APE vs FLAC

Reply #51 – 2003-07-03 06:58:20

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

APE vs FLAC

Reply #52 – 2003-07-03 07:02:53

Quote

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

It would take a second longer...

APE vs FLAC

Reply #53 – 2003-07-03 11:20:25

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

APE vs FLAC

Reply #54 – 2003-07-03 11:55:54

Quote

1. encoding speed: if you are encoding while ripping, encoding speed doesn't really matter as long as it's faster than ripping. it's the decoding speed that counts if you're ever going to play back on anything but a PC.

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!

Quote

3. MAC for the extra compression: for those who gave that reason... if that's the main reason then why not use other codecs that have even higher compression?

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

APE vs FLAC

Reply #55 – 2003-07-03 13:22:15

Quote

1. encoding speed: if you are encoding while ripping, encoding speed doesn't really matter as long as it's faster than ripping. it's the decoding speed that counts if you're ever going to play back on anything but a PC.

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.

Quote

3. MAC for the extra compression: for those who gave that reason... if that's the main reason then why not use other codecs that have even higher compression?

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.

APE vs FLAC

Reply #56 – 2003-07-03 17:35:33

Quote

2. APL for FLAC, or playing FLAC albums as tracks: in winamp2 I think mp3cue works for FLAC also. I expected more players to support playing from embedded cue sheets since the API makes it very easy.

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.

APE vs FLAC

Reply #57 – 2003-07-03 17:41:36

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.

APE vs FLAC

Reply #58 – 2003-07-03 18:25:04

Quote

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.

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...

APE vs FLAC

Reply #59 – 2003-07-03 19:20:38

Quote

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.

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

APE vs FLAC

Reply #60 – 2003-07-03 19:21:30

Quote

Quote
2. APL for FLAC, or playing FLAC albums as tracks: in winamp2 I think mp3cue works for FLAC also. I expected more players to support playing from embedded cue sheets since the API makes it very easy.

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.

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

APE vs FLAC

Reply #61 – 2003-07-03 19:30:10

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

APE vs FLAC

Reply #62 – 2003-07-03 19:54:21

Quote

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:

Code: [Select]

DISCID=b3113f0c
DTITLE=Counting Crows / Glastonbury (23-6-00)
DYEAR=2000
DGENRE=
TTITLE0=Angels of the Silences
TTITLE1=Mr Jones
TTITLE2=I Wish I Was A Girl
TTITLE3=All My Friends
TTITLE4=Omaha
TTITLE5=Have You Seen Me Lately?
TTITLE6=A Murder of One
TTITLE7=Live Forever / A Long December
TTITLE8=Round Here / She Doesn't Exist Anymore
TTITLE9=Mrs Potter's Lullaby
TTITLE10=Rain King / Thunder Road
TTITLE11=Hanginaround (incomplete)

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

APE vs FLAC

Reply #63 – 2003-07-03 21:43:16

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

APE vs FLAC

Reply #64 – 2003-07-05 02:00:11

Quote

FLAC, 'cos it's fast (encoding, decoding, and seemingly seeking), well supported, well specified, and comes free with warm, fuzzy open feelings.

i second that

APE vs FLAC

Reply #65 – 2003-07-05 07:59:29

Quote

some points...

1. encoding speed: if you are encoding while ripping, encoding speed doesn't really matter as long as it's faster than ripping. it's the decoding speed that counts if you're ever going to play back on anything but a PC.

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!

APE vs FLAC

Reply #66 – 2003-07-07 01:35:55

Quote

What about hardware support? I know FLAC has already got some sort of hardware support.

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

APE vs FLAC

Reply #67 – 2003-07-11 17:11:48

Quote

And please tell me why
And which settings do you use?

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

APE vs FLAC

Reply #68 – 2003-07-15 06:55:28

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

Later.

APE vs FLAC

Reply #69 – 2003-07-15 11:54:48

FLAC

Faster seeking...

APE vs FLAC

Reply #70 – 2003-07-15 13:36:57

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

APE vs FLAC

Reply #71 – 2003-07-28 14:22:13

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

APE vs FLAC

Reply #72 – 2003-07-28 14:50:05

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 vs FLAC

Reply #73 – 2003-07-28 15:24:06

APE -extra high .... - -"

APE vs FLAC

Reply #74 – 2003-07-28 15:29:22

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.

Notice

Poll

Which do you prefer