IPB

Welcome Guest ( Log In | Register )

13 Pages V  « < 9 10 11 12 13 >  
Reply to this topicStart new topic
Which is the best lossless codec?, Discussion thread
greynol
post Oct 30 2006, 21:40
Post #251





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



You're right, when you delete some bytes the output from that point forward is pretty much toast.

This post has been edited by greynol: Oct 30 2006, 21:44


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
rjamorim
post Oct 30 2006, 21:46
Post #252


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (greynol @ Oct 30 2006, 17:40) *
You're right, when you delete some bytes the output from that point forward is pretty much toast.


Right. And, for instance, in network transfers, it's much more likely to lose some bits (lose a packet) than get those bits replaced by something else. So, I guess (?) that kind of error is more common.

FLAC and WavPack, on the other hand, somehow manage to resync after missing some bits. I think that's because WavPack and FLAC are packet based. I suspect Monkey's isn't packet based, like WavPack3.

This post has been edited by rjamorim: Oct 30 2006, 21:47


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
greynol
post Oct 30 2006, 21:51
Post #253





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



I thought about what type of corruption would cause missing bits and came up with the same conclusion.

Of course this brings us back to the issue of legal ownership.

I wish your chart had a better ranking/explanation for error handling.


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
guruboolez
post Oct 30 2006, 21:53
Post #254





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



QUOTE (rjamorim @ Oct 30 2006, 22:33) *
So, where are your tests?

Last time (here) I had to bring myself the proof that Greynol's claim was wrong.
A bit like God integrists, Greynol is by defaut right... unless you can prove the opposite.

As I already said in a past topic, I encountered a -c2000 encoded files which was completely unreadable after the error even with Winamp. But as I can't submit it, I'm surely wrong...
Go to the top of the page
+Quote Post
greynol
post Oct 30 2006, 21:58
Post #255





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



This was a good discussion and I learned something from it. It would have been nicer (for me) that the missing bytes issue was addressed in the other thread so that we wouldn't have to go a second round.

You weren't surely wrong, guruboolez, you just never bothered to tell me why, or else I would have found it out myself as I did with Roberto's help. I tried to find your claim about -c2000 encoded files being completely unreadable, sadly I couldn't. I'm not saying that you didn't say that, just that I'd like to read it since it sounds like I offended you by holding you to some sort of standard. (this is reminding me of trumpets wink.gif)

This post has been edited by greynol: Oct 30 2006, 22:07


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
guruboolez
post Oct 30 2006, 22:08
Post #256





Group: Members (Donating)
Posts: 3474
Joined: 7-November 01
From: Strasbourg (France)
Member No.: 420



Tell you what? (it's clearer after your edit)
QUOTE
I tried to find your claim about -c2000 encoded files being completely unreadable, sadly I couldn't

I can't myself. I thought I precised it but obviously I didn't.
But what I don't understand now is why you challenged Roberto to decode a corrupted -c3000 encoding? The previous discussion didn't conclude on the possibility (or impossibility) to decode corrupted ape file according to the profile.

This post has been edited by guruboolez: Oct 30 2006, 22:22
Go to the top of the page
+Quote Post
rjamorim
post Oct 30 2006, 22:14
Post #257


Rarewares admin


Group: Members
Posts: 7515
Joined: 30-September 01
From: Brazil
Member No.: 81



QUOTE (greynol @ Oct 30 2006, 17:51) *
Of course this brings us back to the issue of legal ownership.


Oh, come on... I can have the APE files on my computer and stream them over wi-fi to the media center in my living room. No legal issues whatsoever there.

As for the better explanation on error ranking: sure, as long as someone takes his time to throughtly test all involved codecs.

This post has been edited by rjamorim: Oct 30 2006, 22:19


--------------------
Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:
http://www.rarewares.org
Go to the top of the page
+Quote Post
greynol
post Oct 30 2006, 22:25
Post #258





Group: Super Moderator
Posts: 10009
Joined: 1-April 04
From: San Francisco
Member No.: 13167



Sorry, I was thinking p2p transfers.

@guruboolez:
What do you mean "tell you what?"?
I've found no past topic where you stated -c2000 couldn't decode. Perhaps you can give me a link. My point being was that Roberto was able to explain how a -c2000 file can get corrupted beyond the ability to decode. This was quite a bit more helpful than opting to compare me with a God integrist.

@Roberto: Thanks for acknowledging my comment about the chart. This is all I really ever wanted from you regarding this subject.

EDIT: Would it be too difficult to simply describe the criteria of the test to determine "error handling" in a footnote?

This post has been edited by greynol: Oct 30 2006, 22:31


--------------------
Your eyes cannot hear.
Go to the top of the page
+Quote Post
Alex B
post Oct 30 2006, 23:35
Post #259





Group: Members
Posts: 1303
Joined: 14-September 05
From: Helsinki, Finland
Member No.: 24472



QUOTE (rjamorim @ Oct 30 2006, 22:46) *
Right. And, for instance, in network transfers, it's much more likely to lose some bits (lose a packet) than get those bits replaced by something else. So, I guess (?) that kind of error is more common.

TCP/IP and for example NetBeui are error correcting protocols. You cannot lose a packet because of network errors. Your LAN would be generally unusable before you start losing packets. Naturally you can have faulty hardware like bad memory sticks or broken network adapters that cause errors or your network connection can be too slow for real time playback, but these are different issues.

Even on WAN it is unlikely that a direct file transfer would not be perfect. TCP adjusts its error correction parameters automaticallly when the connection is less than perfect. It just gets slow. Streaming for real time playback is a different story, but this applies only to those lossless formats that can be streamed.

Edit: typo

This post has been edited by Alex B: Oct 31 2006, 00:02


--------------------
http://listening-tests.freetzi.com
Go to the top of the page
+Quote Post
Fifoxtasy
post May 26 2007, 04:41
Post #260





Group: Members
Posts: 205
Joined: 14-June 05
Member No.: 22717



i wish there was an up to date graph like this one on the wiki's comparison page
i think this is by far the best way to present differences in codec performance.
codecs just have too many modes to just put one comression ratio and speed.

This post has been edited by Fifoxtasy: May 26 2007, 04:44
Go to the top of the page
+Quote Post
Allan Gabston-Ho...
post May 31 2007, 19:36
Post #261





Group: Members
Posts: 1
Joined: 31-May 07
Member No.: 43905



I have to find myself questioning the validity of "Doesn't support RIFF chunks" as a 'CON' for any lossless format. The obsolete RIFF structure has not been adopted by any new multimedia formats since the early 90's; and, even microsoft has abandoned it in favor of the DRM-crippled ASF container format.

Comparing ASFs other features against the cadre of other container formats out there, there is nothing compelling about the format which would otherwise foster its adoption. Matroska or NUT are far more worthy container format choices, IMHO.

I am also somewhat confused with regard to defining the lack of hybrid/lossy modes, for any lossless format, as a 'CON'. My perspective is that my choice of a lossless audio format precludes any interest in lossy audio compression scheme, thus rendering any hybrid format as irrelevant. For my needs, that is the exact case.

It seems reasonable to anticipate that, were I to desire a lossy compression storage scheme, I would select a lossy compression format; not a lossless compression format that is trying to be all things to all people; and, in all likelihood, not accomplishing either task very well at all.
Go to the top of the page
+Quote Post
Domenic
post Sep 14 2009, 01:46
Post #262





Group: Members
Posts: 12
Joined: 14-September 09
Member No.: 73163



I'm sorry if it's bad to bump this topic, but FFmpeg now supports ALAC encoding, therefore ALAC has Linux support.
Go to the top of the page
+Quote Post
Dewey, Cheathem ...
post Oct 28 2009, 02:52
Post #263





Group: Members
Posts: 1
Joined: 28-October 09
Member No.: 74383



QUOTE (kotrtim @ Nov 25 2004, 23:40) *
1. LOWER COMPRESSION BUT HIGHER CPU USAGE
2. NO COMPRESSION MODE TO SELECT

EDIT : But compared with Monkey's Audio, WMA still use more power.

WMA = 34.0MB = ~13% CPU Usage
Monkey's Audio - High = 33.7MB = ~7% CPU Usage


I've heard this term used throughout this discussion, but what is "pipe support"?
Go to the top of the page
+Quote Post
bryant
post Oct 28 2009, 04:39
Post #264


WavPack Developer


Group: Developer (Donating)
Posts: 1292
Joined: 3-January 02
From: San Francisco CA
Member No.: 900



Pipe support means that the codec command-line encoder/decoder can accept input from stdin and/or send output to stdout.

Many tools (like foobar) have provisions to use encoders that support stdin to encode without intermediate files, and other programs (like Logitech's SqueezeCenter) can use decoders with stdout support to play otherwise unsupported formats.

And, of course, on Linux everything uses pipes! smile.gif
Go to the top of the page
+Quote Post
Mach-X
post Dec 23 2012, 07:52
Post #265





Group: Members
Posts: 273
Joined: 29-July 12
From: Windsor, On, Ca
Member No.: 101859



This is a ham-fisted reply, but can't we just stick with FLAC for all our lossless archiving needs? Having all these different codecs is confusing. I'm fine with different lossy codecs but for archiving purposes hasn't FLAC been established de facto yet? Its open source, supported natively by sansa's and cowon's excellent daps, as well as android. Am I missing something here? Wouldn't it be better suited for all these different developers to try and improve the FLAC format itself, thereby providing a single universal lossless codec?
Go to the top of the page
+Quote Post
Destroid
post Dec 23 2012, 11:58
Post #266





Group: Members
Posts: 551
Joined: 4-June 02
Member No.: 2220



This thread is ancient, but I'll bite... wink.gif

Yes, there is no inherit downside to FLAC. But people want more. I feel any lossless codec that 'delivers' (input = output) is still worthy and useful. Since lossless compression (in digital data) is visible all over the place (ZIP/RAR/7z/PNG and et cetera) it seems taken for granted. Then there is the issues of support (platform/licensing/third-party software) and versatility.

Nowadays I am much more hippie about lossless audio codecs since I joined HA and I have come to embrace all of the formats smile.gif But I also understand the confusion of the lack of standard lossless audio format. Despite MPEG-4 using the LPAC derivative I have yet to witness its adoption in regards across all areas of consumer audio (I expect parts of its technology might exist in Dolby TrueHD).

The "best" lossless codec? It would appear to be the same as asking, "What is the best formal designer clothing?" It depends on the person and what their expectations are. I guess try them them all out and decide which is most comfortable. Personally, I decided that fixating on a single brand may hinder myself in the long run since all of them are useful and better than going naked (meaning error correction and tagging and so on smile.gif ).

edit: grammar

This post has been edited by Destroid: Dec 23 2012, 12:11


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
ktf
post Dec 30 2012, 16:40
Post #267





Group: Members
Posts: 383
Joined: 22-March 09
From: The Netherlands
Member No.: 68263



Hi guys,

I know this is an ancient thread, but I would like to say something about the wikipage this thread relates to, instead of 'just' editing the wiki without telling why. I did some tests for the lossless comparison I'm currently working on, and I found some results that are quite different from the data in the Wiki.

First, WMA Lossless has, according to the Wiki, compression ratio's surpassing TAK, FLAC and WavPack. This recent comparison shows that's really wrong, and my own comparison tells me the same. I suppose the table states compression ratios associated with the default setting of each encoder, so WMA Lossless should have a ratio higher than FLAC probably. According to my tests, it should be 1.5 percentage point higher.

Second, WMA Lossless is actually pretty fast according to my tests. Could it be they sped up the encoder or changed the preset in the past 8 years? smile.gif

I'll add some graphs of the Windows-part of the tests. First the encoding part: (note this was compared to FLAC -6)


Last the decoding part:


This post has been edited by ktf: Dec 30 2012, 16:51


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post
lvqcl
post Dec 30 2012, 17:35
Post #268





Group: Developer
Posts: 3397
Joined: 2-December 07
Member No.: 49183



QUOTE
According to my tests, it should be 1.5 percentage point higher.
Second, WMA Lossless is actually pretty fast according to my tests. Could it be they sped up the encoder or changed the preset in the past 8 years?


Yes, I noticed this too.
Go to the top of the page
+Quote Post
ktf
post Jun 18 2013, 09:47
Post #269





Group: Members
Posts: 383
Joined: 22-March 09
From: The Netherlands
Member No.: 68263



QUOTE (ktf @ Dec 30 2012, 17:40) *
First, WMA Lossless has, according to the Wiki, compression ratio's surpassing TAK, FLAC and WavPack. This recent comparison shows that's really wrong, and my own comparison tells me the same. I suppose the table states compression ratios associated with the default setting of each encoder, so WMA Lossless should have a ratio higher than FLAC probably. According to my tests, it should be 1.5 percentage point higher.

This is getting really weird.

I got the results from my previous post on an updated Windows 7 computer. I did the conversion through dBpowerAMP with the Windows Media Player 10 Pro release. However, I am migrating my test setup to an old computer running Windows XP (using software mentioned here) and I got some preliminary results that are completely different. It is a different set of samples, but the results shouldn't have this much of a gap really.



Does anyone have any idea why this big difference? These results on Windows XP were with Windows Media Player 11 installed and indicate a pretty slow codec with fairly nice compression ratios, but the results on the Windows 7 computer show a much faster codec, but with less compression. Or could it have to do something with dBpowerAMP?

What should I do with this?

This post has been edited by ktf: Jun 18 2013, 10:11


--------------------
Music: sounds arranged such that they construct feelings.
Go to the top of the page
+Quote Post
TBeck
post Jun 18 2013, 10:07
Post #270


TAK Developer


Group: Developer
Posts: 1098
Joined: 1-April 06
Member No.: 29051



Probably the explaination is a lot simplier, but one quick hypothesis:

1) Maybe the codec is using different filter implementations depending on the available instruction set extensions and/or the cpu speed.
2) Possibly those implementations are not equally accurate mathematically.
Go to the top of the page
+Quote Post
BECHA
post Jul 12 2013, 00:38
Post #271





Group: Members
Posts: 11
Joined: 11-July 13
Member No.: 109066



Best lossless for what?
I stick currently with
1. wavpack
2. FLAC
3. ALAC
4. APE

I use
wavpack for
CD image rips 16/44100
Vinyl image rips 24/96000

FLAC
Vinyl image and tracks rips 24/192000

ALAC
CD tracks rips 16/44100

APE
Vinyl image and tracks rips 24/192000

I listen to my audio collection rips in or at
car
Mostly wavpack and flac using Kamerton Android application and stream to car's HU

work
Mostly wavpack and flac using Kamerton Android application direct Grado headphones connection

Home
wavpack, FLAC, APE, ALAC from laptop USB connected headphone amplifier to Shure headphones, application MediaChest
wavpack, FLAC, APE, ALAC from Raspberry Pi HDMI connected to Denon receiver, application Music Barrel

So far I found wavpack as my best choice, reasons are
1. versitile format but suitable more for keeping images
2. Flexibility in packaging as single .wv or ISO packaged
3. Suitable for bit rates up to 24/192000
4. Allows seek without additional navigation table as FLAC or APE require
5. Reasonable CPU consumption, you can observe that my playing devices either Android phones or Raspberry Pi

So verdict is
WAVPACk is the winner!

Second place is shared by FLAC and ALAC, and 3rd place goes to APE.
Go to the top of the page
+Quote Post
Porcus
post Jul 12 2013, 20:54
Post #272





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (BECHA @ Jul 12 2013, 01:38) *
Vinyl image rips 24/96000
[...]
Vinyl image and tracks rips 24/192000


... well ... ehm ... I should know better than asking, but ... why?


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post
boombaard
post Aug 19 2013, 14:45
Post #273





Group: Members
Posts: 336
Joined: 7-February 05
From: Local Cluster
Member No.: 19647



QUOTE (Porcus @ Jul 12 2013, 21:54) *
QUOTE (BECHA @ Jul 12 2013, 01:38) *
Vinyl image rips 24/96000
[...]
Vinyl image and tracks rips 24/192000


... well ... ehm ... I should know better than asking, but ... why?

to inflate the file size, of course! Or perhaps because of the overtones being 'preserved'. Or perhaps it's because we will shortly be able to GM our ears so that we will be able to hear everything up to 40kHz?
There's a few vinyl digitization efforts going on on various classical blogs that believe strongly in the value of digitizing at 96k/24 or 192k/24; I don't mind because foobar can dither, but it seems a bit of a waste of disk space..

This post has been edited by boombaard: Aug 19 2013, 14:46
Go to the top of the page
+Quote Post
bennetng
post Jan 4 2014, 19:58
Post #274





Group: Members
Posts: 224
Joined: 22-December 05
Member No.: 26587



flac
+ high compatibility over different hard/software, ultra-fast encoder (flaccl)
- no floating point support

wavpack
+ floating point support to archive DAW exports without worrying about dithering/clipping/normalizing.
- not as popluar as flac

Other formats are pretty useless for me, don't really care about slight file size variations among different formats as they are already much smaller than uncompressed formats.

This post has been edited by bennetng: Jan 4 2014, 20:06
Go to the top of the page
+Quote Post
tuxman
post Jan 29 2014, 19:40
Post #275





Group: Members
Posts: 188
Joined: 24-April 07
From: Northern Germany
Member No.: 42855



Hmm,

when I started compressing my CDs as lossless audio files, FLAC was the most widely spread format which also worked on my mobile "MP3" player, so there was no choice.

These days, as I find myself mainly listening to music on my laptop and my smartphone (with headphones), I'm not sure if I should try TAK instead. (Admittedly, TAK support for my music playing app is still "planned".) How's the common conception for this?


--------------------
audiophile // FLAC and Vorbis user // Winamp addict
Go to the top of the page
+Quote Post

13 Pages V  « < 9 10 11 12 13 >
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 30th September 2014 - 08:41