IPB

Welcome Guest ( Log In | Register )

13 Pages V  « < 4 5 6 7 8 > »   
Reply to this topicStart new topic
Which is the best lossless codec?, Discussion thread
rjamorim
post Mar 7 2005, 11:02
Post #126


Rarewares admin


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



QUOTE (spoon @ Mar 7 2005, 06:58 AM)
IMHO something is only open source if it is controlled by those who release the open source code - FLAC is.
*


From an ideological point of view, you are correct. But from a practical - I.E, the end user's - point of view, it makes no difference who is releasing the sources, as long as they can decode the bitstreams.

This post has been edited by rjamorim: Apr 12 2005, 23:03


--------------------
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
Mr_Rabid_Teddybe...
post Mar 8 2005, 01:13
Post #127





Group: Members
Posts: 1197
Joined: 3-September 03
From: Bergen, Norway
Member No.: 8667



QUOTE (Mo0zOoH @ Mar 6 2005, 03:53 PM)
Seems like Wavpack and FLAC are the most “green” out there. smile.gif
Too bad they're not very good at compression ratio…
*

Well, that depends.... If you use the x switch with Wavpack you can achive some mighty good compression, but it's mighty slow too....
I recently compressed some improv disks with wavpack -hxmt and got results in the range of 30-40% of original wavs. Now I guess that's much due to the music; like much classical, improv is music with much "air" in it, as opposed to e.g. contemporay pop or metal, but still I found this quite impressive. It was veeeery slow, though, unlike wavpack at default settings, which is what's used for rjamorim's table.


--------------------
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
- Oceania Association of Autonomous Astronauts
Go to the top of the page
+Quote Post
Mono
post Mar 8 2005, 04:04
Post #128





Group: Members (Donating)
Posts: 295
Joined: 4-December 03
From: Alabama
Member No.: 10171



QUOTE (Mono @ Mar 6 2005, 06:59 PM)
QUOTE (rjamorim @ Mar 6 2005, 10:20 AM)
Ah, very interesting. I tried feeding a multichannel stream to my iTunes and my QuickTime, as well as a high-frequency stream, and both programs choked on both streams.

I wonder if the MacOS versions of these programs don't show these limitations.
*

I've got samples on my Win desktop. I'll transfer them to my iBook tomorrow and test it out.
*


The multichannel file choked iTunes and QuickTime, which I didn't expect. I know that lots of users work with multichannel files on Macs. The hi res file played fine, encoded fine, but the decoder output a 44.1 kHz stream (the original was 96 kHz).


--------------------
"Facts do not cease to exist just because they are ignored."
—Aldous Huxley
Go to the top of the page
+Quote Post
shadowking
post Mar 8 2005, 13:35
Post #129





Group: Members
Posts: 1523
Joined: 31-January 04
Member No.: 11664



QUOTE (Mr_Rabid_Teddybear @ Mar 7 2005, 04:13 PM)
QUOTE (Mo0zOoH @ Mar 6 2005, 03:53 PM)
Seems like Wavpack and FLAC are the most “green” out there. smile.gif
Too bad they're not very good at compression ratio…
*

Well, that depends.... If you use the x switch with Wavpack you can achive some mighty good compression, but it's mighty slow too....
I recently compressed some improv disks with wavpack -hxmt and got results in the range of 30-40% of original wavs.
*




-h by itself is comparable to Monkeys audio normal mode.


--------------------
Wavpack -b450
Go to the top of the page
+Quote Post
moozooh
post Mar 8 2005, 14:30
Post #130





Group: Members
Posts: 357
Joined: 22-September 04
From: Moscow
Member No.: 17192



QUOTE (Mr_Rabid_Teddybear @ Mar 7 2005, 04:13 PM)
Well, that depends.... If you use the x switch with Wavpack you can achive some mighty good compression, but it's mighty slow too....
I recently compressed some improv disks with wavpack -hxmt and got results in the range of 30-40% of original wavs.
*

QUOTE (shadowking @ Mar 8 2005, 03:35 PM)
-h by itself is comparable to Monkeys audio normal mode.
*

Are these swithes enabled by default? huh.gif AFAIK, this comparison table is based on every encoder's default settings…


--------------------
Infrasonic Quartet + Sennheiser HD650 + Microlab Solo 2 mk3. 
Go to the top of the page
+Quote Post
Mr_Rabid_Teddybe...
post Mar 9 2005, 01:52
Post #131





Group: Members
Posts: 1197
Joined: 3-September 03
From: Bergen, Norway
Member No.: 8667



QUOTE (Mo0zOoH @ Mar 8 2005, 05:30 AM)
Are these swithes enabled by default? huh.gif AFAIK, this comparison table is based on every encoder's default settings…
*

If i understood this right, and rjamorim has used it without specifying switches, then Wavpack just uses it's default settings. AFAIK neither -h nor -x are turned on by default. In Wavpacks pure lossless mode -h and -x are switches you can play with for that extra compression, at the cost of speed. The -h switch makes both encoding and decoding about twice as slow, the -x switch turns on asymmetrical mode and makes encoding very, very, veeery much slower, but don't hurt decoding speed. So -hx gives you Wavpacks best compression and slowest encoding.


--------------------
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
- Oceania Association of Autonomous Astronauts
Go to the top of the page
+Quote Post
Ariakis
post Mar 9 2005, 02:28
Post #132





Group: Members (Donating)
Posts: 145
Joined: 26-March 03
Member No.: 5677



QUOTE (Mr_Rabid_Teddybear @ Mar 8 2005, 07:52 PM)
So -hx gives you Wavpacks best compression and slowest encoding.
*


Actually, -hx6 would give you the best compression, as the -x switch alone will give you different parameters depending on the compression level.

QUOTE
This option accepts an optional numberic parameter from 1 to 6 that overrides the default amount of "extra" processing done. The defaults were choosen to provide the greatest "bang for the buck" and are -x6 for "fast" mode, -x4 for the normal mode and -x3 for the "high" mode.

That's straight from the WavPack manual. =)
Go to the top of the page
+Quote Post
Mr_Rabid_Teddybe...
post Mar 9 2005, 03:06
Post #133





Group: Members
Posts: 1197
Joined: 3-September 03
From: Bergen, Norway
Member No.: 8667



QUOTE (Ariakis @ Mar 8 2005, 05:28 PM)
Actually, -hx6 would give you the best compression, as the -x switch alone will give you different parameters depending on the compression level.
*

Yes, I know that, but -hx was slow enough for me.... wink.gif


--------------------
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL ACHIEVE THE ABSURD"
- Oceania Association of Autonomous Astronauts
Go to the top of the page
+Quote Post
rjamorim
post Mar 9 2005, 15:57
Post #134


Rarewares admin


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



QUOTE (Mo0zOoH @ Mar 6 2005, 08:53 PM)
Seems like Wavpack and FLAC are the most “green” out there. smile.gif
*


Indeed. If the RockBox guys release their unofficial iRiver firmware with WavPack support, and if Kuniklo finishes the XMMS plugin, WavPack will be the only all-green format in the table.



I just edited the table. ALAC's open-sourceness becomes light green and it's not featuring multichannel and high resolution anymore since no implementation supports them. If QuickTime 7 adds these features, I'll change the table back.

This post has been edited by rjamorim: Mar 9 2005, 16:02


--------------------
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
rutra80
post Mar 16 2005, 00:57
Post #135





Group: Members (Donating)
Posts: 810
Joined: 12-September 03
Member No.: 8821



Few concerns about OptimFROG column:
1. Why ReplayGain row says "no"? I have all my OFR files replaygained by fb2k, values are stored inside the file's APEv2 tags, and they get gained on replay, isn't it ReplayGain support?
2. Pipe support row is blank, while "ofr.exe - --output %d" in fb2k's DiskWriter works, so I guess it supports pipes?
3. Why Encoding & Decoding speed rows say "slow"? As Flexibility row says, it's very flexible. With default settings it's at least average, and surely can be fast with proper settings.

This post has been edited by rutra80: Mar 16 2005, 01:16
Go to the top of the page
+Quote Post
rjamorim
post Mar 16 2005, 01:27
Post #136


Rarewares admin


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



QUOTE (rutra80 @ Mar 15 2005, 08:57 PM)
1. Why ReplayGain row says "no"? I have all my OFR files replaygained by fb2k, values are stored inside the file's APEv2 tags, and they get gained on replay, isn't it ReplayGain support?


That only means Foobar supports replaygain, not that Optimfrog supports replaygain.

It's the same situation with Monkey's. If features require that the format user is locked to a third party software, then it's not a format feature, but a third party software feature.

QUOTE
2. Pipe support row is blank, while "ofr.exe - --output %d" in fb2k's DiskWriter works, so I guess it supports pipes?


Yes, it does. I'll add that to the table. Thanks for looking into that.

A blank cell means I don't know about that feature, so any information is welcome.

QUOTE
3. Why Encoding & Decoding speed rows say "slow"? As Flexibility row says, it's very flexible. With default settings it's at least average, and surely can be fast with proper settings.
*


I always use Hans Heijden's lossless comparision to evaluate speed vs. efficiency, etc. By "slow", I consider codecs that encode at less than 10X real time in the default setting. Even in the fast setting, OptimFrog encodes slower than 10X...

And I chose to represent only the default setting because the table would become a mess if I tried to evaluate the efficiency of every setting. It's also the developer duty to make the default setting output the best "bang for the buck" for users.

This post has been edited by rjamorim: Mar 16 2005, 01:40


--------------------
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
rutra80
post Mar 18 2005, 03:36
Post #137





Group: Members (Donating)
Posts: 810
Joined: 12-September 03
Member No.: 8821



Another idea - how about adding a "Size limit" row? I read that even WAV has a 2GB limit and I know that some lossless encoders have internal limits too (not related with file-system or other things).
Go to the top of the page
+Quote Post
rjamorim
post Mar 18 2005, 03:59
Post #138


Rarewares admin


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



QUOTE (rutra80 @ Mar 17 2005, 11:36 PM)
Another idea - how about adding a "Size limit" row? I read that even WAV has a 2GB limit and I know that some lossless encoders have internal limits too (not related with file-system or other things).
*


Well, if someone is willing to test each codec's limits...

Problem is, most of them read from wavs. So, you would have to make a wav several gigabytes big in order to test them, and such wav would be corrupt because of that same limitation.

This post has been edited by rjamorim: Mar 18 2005, 04:00


--------------------
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
Cyaneyes
post Mar 18 2005, 04:11
Post #139





Group: Members
Posts: 297
Joined: 21-September 03
Member No.: 8934



QUOTE (rjamorim @ Mar 17 2005, 09:59 PM)
Well, if someone is willing to test each codec's limits...

Problem is, most of them read from wavs. So, you would have to make a wav several gigabytes big in order to test them, and such wav would be corrupt because of that same limitation.
*


See my last post in this thread from last month. The wav I was encoding was 5.5 hours, 44.1/16, size about 3.5 GB
Go to the top of the page
+Quote Post
kjoonlee
post Mar 18 2005, 04:31
Post #140





Group: Members
Posts: 2526
Joined: 25-July 02
From: South Korea
Member No.: 2782



QUOTE (rjamorim @ Mar 18 2005, 11:59 AM)
QUOTE (rutra80 @ Mar 17 2005, 11:36 PM)
Another idea - how about adding a "Size limit" row? I read that even WAV has a 2GB limit and I know that some lossless encoders have internal limits too (not related with file-system or other things).
*


Well, if someone is willing to test each codec's limits...

Problem is, most of them read from wavs. So, you would have to make a wav several gigabytes big in order to test them, and such wav would be corrupt because of that same limitation.
*


This is only a partial solution, but here goes..

If they support pipes, and if they support raw PCM, they could be fed raw gigabytes from standard input. You could just feed the encoder repeated pieces of small audio files this way.


--------------------
http://blacksun.ivyro.net/vorbis/vorbisfaq.htm
Go to the top of the page
+Quote Post
rjamorim
post Apr 10 2005, 21:55
Post #141


Rarewares admin


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



Small change: WavPack software support goes from average to good, thanks to the recent release of Kuniklo's beta XMMS plugin and Toff's alpha directshow filters.


--------------------
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
Skymmer
post Apr 12 2005, 20:53
Post #142





Group: Members
Posts: 114
Joined: 11-June 03
Member No.: 7132



QUOTE (smack @ Feb 22 2005, 02:57 PM)
Just want to add some details about LA to your great comparison table:

-tagging is possible  (I'm using Tag.exe to add APE2 tags, the Winamp plugin can display them, the command line decoder ignores them)

-PIPE is supported  (I'm using it in my small "la2mp3.bat" script - la.exe pipes decoded data to lame.exe)
*

Well I don't want to say that you lie but probably you're just little bit confused. I've tried MultiFrontend and LA Frontend with APEv1/APEv2 tags and also Foobar's Diskwriter Commandline Encoder with selected APEv2 tag and found that Winamp doesn't support APEv2 tags. Tried both 0.4 and 0.4b. Foobar does but it's more native Foobar functionality than support from format. Furthermore official documentation of LA says: ID3 v1.1 tagging support


--------------------
Gabber, Jazz and IDM
Go to the top of the page
+Quote Post
rjamorim
post Apr 13 2005, 03:03
Post #143


Rarewares admin


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



Thanks for spotting it. I just updated the table and post.


Edit: I wonder if ID3v1-only support shouldn't be in "cons" instead of "pros" :B

This post has been edited by rjamorim: Apr 13 2005, 03:32


--------------------
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
guruboolez
post Apr 13 2005, 14:04
Post #144





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



I've just noticed the blank cell for "pipe support" and WMA lossless. Pipe seems to be OK: I can transcode directly a WMA LSL file to another formats (lossy and lossless) with foobar2000.

EDIT: iTunes is also able to import WMA LSL file without needing a temporary decoding file.

This post has been edited by guruboolez: Apr 13 2005, 14:05
Go to the top of the page
+Quote Post
rjamorim
post Apr 13 2005, 16:27
Post #145


Rarewares admin


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



QUOTE (guruboolez @ Apr 13 2005, 10:04 AM)
I've just noticed the blank cell for "pipe support" and WMA lossless. Pipe seems to be OK: I can transcode directly a WMA LSL file to another formats (lossy and lossless) with foobar2000.

EDIT: iTunes is also able to import WMA LSL file without needing a temporary decoding file.
*


Thanks, I just amended the table and the post.


--------------------
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
rjamorim
post Apr 13 2005, 16:30
Post #146


Rarewares admin


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



Also, I suggest you guys check out the Wiki entry that is a copy of the first post in this thread:
http://wiki.hydrogenaudio.org/index.php?ti...ess_comparision

I think Jan S. will eventually redirect this thread to the wiki. It's a better solution, since in that case everyone can change and correct the article, and not only me.

This post has been edited by rjamorim: Apr 13 2005, 16:31


--------------------
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
Digga
post Apr 13 2005, 17:00
Post #147





Group: Members
Posts: 1047
Joined: 28-June 03
From: on the dock of the bay
Member No.: 7423



QUOTE (rjamorim @ Nov 26 2004, 05:14 AM)
FLAC
CONS
- Compression efficiency not on par with other lossless codecs

------------------------

WavPack
PROS
- Good efficiency (not as good as Monkey's or OptimFrog, but not as bad as SHN or ALAC)
hmm, did you decide on a point where you call a codec not on par that lead to WavPack not falling into that category (i.e. everything above 58.0%)?
considering the difference btw FLAC and WavPack is only 0.70% in default mode and FLAC and ALAC are also very close, the quoted statements look a bit irritating.
I would suggest to change WavPack also to 'Compression efficiency not on par with other lossless codecs' or at least to remove the 'good efficiency' part.


--------------------
Nothing but a Heartache - Since I found my Baby ;)
Go to the top of the page
+Quote Post
rjamorim
post Apr 13 2005, 17:08
Post #148


Rarewares admin


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



QUOTE (Digga @ Apr 13 2005, 01:00 PM)
hmm, did you decide on a point where you call a codec not on par that lead to WavPack not falling into that category (i.e. everything above 58.0%)?
considering the difference btw FLAC and WavPack is only 0.70% in default mode and FLAC and ALAC are also very close, the quoted statements look a bit irritating.
I would suggest to change WavPack also to 'Compression efficiency not on par with other lossless codecs' or at least to remove the 'good efficiency' part.
*


Good point. I based that mostly on a Garf's statement that is hidden in some other thread (JanS is working on the redirection)

BTW: It's important to mention that efficiency is not compression ratio. Efficiency is a relation between compression ratio and encoding speed.

I'll look into that issue further, based on Hans Heijden's findings, and edit the wiki if appropriate. The first post in this thread will soon be deleted in favour of the wiki article, so no point working on it any more.

Also: Yes, 58% is the line I drew to separate green compression to light green compression.

This post has been edited by rjamorim: Apr 13 2005, 17:09


--------------------
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
Digga
post Apr 13 2005, 17:12
Post #149





Group: Members
Posts: 1047
Joined: 28-June 03
From: on the dock of the bay
Member No.: 7423



QUOTE (rjamorim @ Apr 13 2005, 05:08 PM)
BTW: It's important to mention that efficiency is not compression ratio. Efficiency is a relation between compression ratio and encoding speed.
ah yes, you're right, I totally forgot about that.
QUOTE
Also: Yes, 58% is the line I drew to separate green compression to light green compression.
what about TTA and LPAC vs. FLAC and ALAC? both are either above or below the 58% mark and both are light green...
QUOTE
The first post in this thread will soon be deleted in favour of the wiki article, so no point working on it any more
o.k. fair enough.

This post has been edited by Digga: Apr 13 2005, 17:15


--------------------
Nothing but a Heartache - Since I found my Baby ;)
Go to the top of the page
+Quote Post
rjamorim
post Apr 13 2005, 17:27
Post #150


Rarewares admin


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



QUOTE (Digga @ Apr 13 2005, 01:12 PM)
what about TTA and LPAC vs. FLAC and ALAC? both are either above or below the 58% mark and both are light green...
*


Oops, sorry about that. Actually 57% is the line.

I considering making 58% the line once, but that would result in too many dark green cells, so it wouldn't be useful for comparision purposes.

This way, it is more or less equilibrated: 4 dark green and 4 light green.

In the comparision, I replaced "Compression efficiency not on par with other lossless codecs" with "Relatively slow encoding" (that is, comparing to other codecs that compress much more at same speed). I think it's fairer towards FLAC. Do you agree?


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

13 Pages V  « < 4 5 6 7 8 > » 
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: 24th July 2014 - 05:04