Commit 0e6187c4 authored by Josh Coalson's avatar Josh Coalson

minor formatting

parent 7581d121
......@@ -53,9 +53,9 @@
</div>
<div class="box_header"></div>
<div class="box_body">
This is an informal changelog, a summary of changes in each release. Particulary important for developers is the precise description of changes to the library interfaces. See also the <a href="http://flac.sourceforge.net/api/group__porting.html">porting guide</a> for specific instructions on porting to newer versions of FLAC.
This is an informal changelog, a summary of changes in each release. Particulary important for developers is the precise description of changes to the library interfaces. See also the <a href="http://flac.sourceforge.net/api/group__porting.html">porting guide</a> for specific instructions on porting to newer versions of FLAC.<br />
<br /><br />
<br />
<a name="flac_1_1_3"><b>FLAC 1.1.3</b></a>
......
......@@ -62,16 +62,16 @@
The compression ratios and times for flac are representative only of the reference encoder. They are not indicative of the limits of all FLAC encoders or the FLAC format itself since the format is open and extensible, and anyone is free to write a better FLAC encoder.
</li>
</ul>
I make an effort to keep this information as accurate as possible, but if any of the data is wrong, <a href="mailto:jcoalson@users.sourceforge.net">let me know</a> and I'll correct it. For another comparison (with graphs) of lossless codecs, see <a href="http://web.inter.nl.net/users/hvdh/lossless/lossless.htm">here</a>.
<br /><br />
I make an effort to keep this information as accurate as possible, but if any of the data is wrong, <a href="mailto:jcoalson@users.sourceforge.net">let me know</a> and I'll correct it. For another comparison (with graphs) of lossless codecs, see <a href="http://web.inter.nl.net/users/hvdh/lossless/lossless.htm">here</a>.<br />
<br />
Note: the comparison tables are getting a little stale for some of the other encoders; for some alternate comparisons and other lossless information see these links:
<ul>
<li><a href="http://web.inter.nl.net/users/hvdh/lossless/lossless.htm">Hans Heijden's</a> lossless comparison</li>
<li><a href="http://wiki.hydrogenaudio.org/index.php?title=Lossless_comparison">Roberto Amorim's</a> lossless comparison on Hydrogenaudio</li>
<li><a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=33226">"Which is the best lossless codec?"</a> thread on Hydrogenaudio</li>
<li><a href="http://www.losslessaudioblog.com/">Lossless Audio Blog</a></li>
</ul>
<br /><br />
</ul><br />
<br />
Reviewed encoders (besides flac of course):
<ul>
<li>
......@@ -105,8 +105,8 @@
<a href="http://www.wavpack.com/">WavPack</a> - An open-source codec, released under the BSD license. WavPack has a very good tradeoff between compressed size and compression speed.
</li>
</ul>
If you take maximum compression ratio and speed out of the picture (as you will see later, most coders exhibit similar performance), here is a subjective sort based on overall "usefulness". As far as features go, having source code gives you the most freedom since you can add anything you need that is missing; besides, open source projects tend to get better faster than closed source ones. A close second (depending on the user) would be OS support or plugin support.
<br /><br />
If you take maximum compression ratio and speed out of the picture (as you will see later, most coders exhibit similar performance), here is a subjective sort based on overall "usefulness". As far as features go, having source code gives you the most freedom since you can add anything you need that is missing; besides, open source projects tend to get better faster than closed source ones. A close second (depending on the user) would be OS support or plugin support.<br />
<br />
<table width="100%" border="0" cellspacing="0" cellpadding="0" bgcolor="#EEEED4"><tr><td>
<table width="100%" border="1" bgcolor="#EEEED4">
<tr>
......@@ -425,14 +425,14 @@
</td></tr></table>
<br />
The machine I used for encoding the test files is a PII-333 with 256 megs of RAM, running Windows NT 4.0 SP5. Unfortunately, Windows is the lowest-common-denominator platform for all the encoders. Apple Lossless was tested on a newer machine (P4-2.4GHz Windows 2000); only the overall encoding and decoding times are shown, and the times are scaled to the PII-333 by multiplying by the ratio of flac times on the PII to P4.
<br /><br />
The input corpus currently consists entirely of CD music tracks. In the future it may include more kinds of input (like speech, other sample rates/resolutions, etc). There are 14 tracks whose genres range from rock to pop to death metal to classical to chant.
<br /><br />
The first table is a summary of results on all input tracks. The remaining tables show the results of the encoders on each track. The summary table has more modes, whereas the individual tables have just the interesting ones.
<br /><br />
In the summary table, entries are sorted by average compression ratio, which is the average of the ratios for each track; this keeps long tracks from having more influence than short ones. In the individual tables, this is the same as the straight compression ratio, which is compressed size / uncompressed size.
<br /><br />
The machine I used for encoding the test files is a PII-333 with 256 megs of RAM, running Windows NT 4.0 SP5. Unfortunately, Windows is the lowest-common-denominator platform for all the encoders. Apple Lossless was tested on a newer machine (P4-2.4GHz Windows 2000); only the overall encoding and decoding times are shown, and the times are scaled to the PII-333 by multiplying by the ratio of flac times on the PII to P4.<br />
<br />
The input corpus currently consists entirely of CD music tracks. In the future it may include more kinds of input (like speech, other sample rates/resolutions, etc). There are 14 tracks whose genres range from rock to pop to death metal to classical to chant.<br />
<br />
The first table is a summary of results on all input tracks. The remaining tables show the results of the encoders on each track. The summary table has more modes, whereas the individual tables have just the interesting ones.<br />
<br />
In the summary table, entries are sorted by average compression ratio, which is the average of the ratios for each track; this keeps long tracks from having more influence than short ones. In the individual tables, this is the same as the straight compression ratio, which is compressed size / uncompressed size.<br />
<br />
Some interesting things to note:
<ul>
<li>flac -5 is right in the middle with respect to compression, relatively fast on the encoding range, and one of the fastest decoding. This is about what you would expect; FLAC is designed to put most of the processing on the encoding side, which is only done once, whereas the adaptive codecs take as long to decode as encode. FLAC is more suited in this way for playback on low-power devices and is one of the reasons it is the only lossless codec with any kind of hardware support.</li>
......@@ -440,8 +440,8 @@
<li>RKAU also has a tendency to get bigger in the 'high' mode.</li>
<li>Another ironic fact is that the encoders that are patented or cost money turn out to be the worst by most measures. SPS is so archane and crippled that I gave up trying to put together results for it after one track.</li>
</ul>
This is a summary table with just the most 'economic' modes (the ones that give the most compression for the least amount of encode/decode time) for each codec.
<br /><br />
This is a summary table with just the most 'economic' modes (the ones that give the most compression for the least amount of encode/decode time) for each codec.<br />
<br />
<table width="100%" border="0" cellspacing="0" cellpadding="0" bgcolor="#EEEED4"><tr><td>
<table width="100%" border="1" bgcolor="#EEEED4">
......
......@@ -53,8 +53,8 @@
</div>
<div class="box_header"></div>
<div class="box_body">
FLAC is an open source project and we are happy to enlist the help of anyone who wants to contribute. The preferred method for transmitting improvements is patch files (in "diff -c" format) sent to the <a href="http://lists.xiph.org/mailman/listinfo/flac-dev">developer mailing list</a>, but zipped up sources are OK. Make sure to read the <a href="goals.html">FLAC goals</a> first; there are some thing the we <b>don't</b> want added to FLAC, like copy protection and lossy compression.
<br /><br />
FLAC is an open source project and we are happy to enlist the help of anyone who wants to contribute. The preferred method for transmitting improvements is patch files (in "diff -c" format) sent to the <a href="http://lists.xiph.org/mailman/listinfo/flac-dev">developer mailing list</a>, but zipped up sources are OK. Make sure to read the <a href="goals.html">FLAC goals</a> first; there are some thing the we <b>don't</b> want added to FLAC, like copy protection and lossy compression.<br />
<br />
High priority items are:
<ul>
<li>
......
This diff is collapsed.
......@@ -115,10 +115,10 @@
</div>
<div class="box_header"></div>
<div class="box_body">
<b>NOTE: </b> these extras are not part of the FLAC project. Most (except those marked [$]) are freely available but distributed under their authors' own terms.
<br /><br />
<b>NOTE: </b> make sure to check out the <a href="links.html">links page</a> for a large list of open-source software supporting FLAC.
<br /><br />
<b>NOTE: </b> these extras are not part of the FLAC project. Most (except those marked [$]) are freely available but distributed under their authors' own terms.<br />
<br />
<b>NOTE: </b> make sure to check out the <a href="links.html">links page</a> for a large list of open-source software supporting FLAC.<br />
<br />
<b>GUI encoding/decoding front-ends:</b>
<ul>
<li>
......
This diff is collapsed.
This diff is collapsed.
......@@ -118,12 +118,12 @@
<li><a href="http://www.digitalnetworksna.com/shop/_templates/item_main_Rio.asp?model=220&amp;cat=53">Rio Karma</a><!-- and Rio Chroma--></li>
<li>TrekStor's <a href="http://www.trekstor.de/en/products/detail_mp3.php?pid=66">Vibez</a></li>
</ul>
<a name="review"><b>Reviews:</b></a>
<br /><br />
The main purpose of these reviews is to give an idea of how well particular devices support FLAC. Other subjective comments here are based on our general impressions and are not meant to be thorough or authoritative. We only review devices we have tested directly ourselves.
<br /><br />
<a name="review_rio_receiver"><a href="http://www.mock.com/receiver/"><b>Rio Reciever</b></a></a>: This little device is a hacker's dream. It plays audio over a network (Ethernet or HPNA) so it requires a PC to serve audio files. There are several open source clients available and since it boots its Linux distro over NFS you can write your own client. They're not made anymore but you can still find them on ebay. The main downsides: 1) small, hard-to-read LCD display; 2) FLAC support is only in third-party clients which take some work to set up.
<br /><br />
<a name="review"><b>Reviews:</b></a><br />
<br />
The main purpose of these reviews is to give an idea of how well particular devices support FLAC. Other subjective comments here are based on our general impressions and are not meant to be thorough or authoritative. We only review devices we have tested directly ourselves.<br />
<br />
<a name="review_rio_receiver"><a href="http://www.mock.com/receiver/"><b>Rio Reciever</b></a></a>: This little device is a hacker's dream. It plays audio over a network (Ethernet or HPNA) so it requires a PC to serve audio files. There are several open source clients available and since it boots its Linux distro over NFS you can write your own client. They're not made anymore but you can still find them on ebay. The main downsides: 1) small, hard-to-read LCD display; 2) FLAC support is only in third-party clients which take some work to set up.<br />
<br />
<a name="review_squeezebox2"><a href="http://www.slimdevices.com/"><b>Squeezebox2</b></a></a>: A fantastic networked audio player. Has an excellent, easy-to-read vacuum fluorescent display, wired or wireless networking, optical and coax digital outs and analog out, a reputation for very high audio quality, multi-room synchronization, and a bunch of other features. The server-side software, SlimServer, is open-source, runs on Windows, Mac OS X, Linux, etc. and has an active community. FLAC support is excellent; nearly the full <a href="format.html#subset">subset</a> (e.g. sample rates up to 48kHz, 16- and 24-bits per sample) including all standard encoding modes are supported. Also supported are FLAC tags, automatic transcoding on the server of many audio formats to FLAC for transmission to the box, and external cuesheet support (internal cuesheet support is in the works).
</div>
<div class="box_footer"></div>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment