I scanned the website with linkchecker and found quite a lot of
dead links. This commit fixes or removes them.
---
developers.html | 2 +-
documentation_tasks.html | 2 +-
download.html | 12 ++++++------
faq.html | 2 +-
features.html | 2 +-
feeds/feed.xml | 8 ++++++++
format.html | 8 ++++----
ogg_mapping.html | 4 ++--
8 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/developers.html b/developers.html
index 87f0a9a..9387cd3 100644
--- a/developers.html
+++ b/developers.html
@@ -102,7 +102,7 @@
<b>Anti-goals</b><br />
<ul>
<li>
- Lossy compression. There are already many suitable lossy formats (<a
href="http://www.xiph.org/ogg/vorbis/index.html">Ogg
Vorbis</a>, <a
href="http://www.mp3-tech.org/">MP3</a>, etc.).
+ Lossy compression. There are already many suitable lossy formats (<a
href="http://www.xiph.org/vorbis/">Ogg Vorbis</a>, <a
href="http://www.mp3-tech.org/">MP3</a>, etc.).
</li>
<li>
Copy prevention, DRM, etc. There is no intention to add any copy
prevention methods. Of course, we can't stop someone from encrypting a FLAC
stream in another container (e.g. the way Apple encrypts AAC in MP4 with
FairPlay), that is the choice of the user.
diff --git a/documentation_tasks.html b/documentation_tasks.html
index 2af4064..0a28d02 100644
--- a/documentation_tasks.html
+++ b/documentation_tasks.html
@@ -157,7 +157,7 @@
<br />
<b>To play FLAC files</b>:
<ul>
- <li><a
href="http://alsaplayer.org/">AlsaPlayer</a></li>
+ <li><a
href="http://alsaplayer.sourceforge.net/">AlsaPlayer</a></li>
<li><a
href="http://amarok.kde.org/">Amarok</a></li>
<li><a
href="http://www.mplayerhq.hu/">MPlayer</a></li>
<li><a
href="http://muine.gooeylinux.org/">Muine</a>: a music player
for GNOME</li>
diff --git a/download.html b/download.html
index 3a94bfc..6d2a339 100644
--- a/download.html
+++ b/download.html
@@ -52,13 +52,13 @@
<ul>
<li><b>Source code</b>: <a
href="http://downloads.xiph.org/releases/flac/">tarballs for stable
and beta releases</a>; also includes documentation and build systems for
Windows (MSVC++) and *nix, *BSD, OS/2, OS X (autotools). You can also take a
look at the <a
href="https://git.xiph.org/?p=flac.git;a%3Dsummary">Development
<b>git repository</b></a></li>
<li><b>Linux</b>: most distributions have a FLAC package,
use the package manager to get FLAC. If not, try <a
href="http://rpmfind.net/linux/rpm2html/search.php?query=flac">rpmfind.net</a>
or <a
href="http://packages.debian.org/cgi-bin/search_packages.pl?keywords=flac&searchon=names&subword=1&version=all&release=all">Debian's
packages</a></li>
- <li><b>Windows</b>: <a
href="http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=12675">FLAC
for Windows (command-line tools only)</a></li>
- <li><b>Mac OS X</b>: <a
href="http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=32318">FLAC
tools for OS X</a>. The .dmg file is an installer and the .tar.gz file is
a tarball.</li>
+ <li><b>Windows</b>: <a
href="http://sourceforge.net/projects/flac/files/flac-win/">FLAC
for Windows (command-line tools only)</a></li>
+ <li><b>Mac OS X</b>: <a
href="http://sourceforge.net/projects/flac/files/flac-darwin/">FLAC
tools for OS X</a>. The .dmg file is an installer and the .tar.gz file is
a tarball.</li>
<li><b>Amiga</b>: <a
href="http://amiga.sourceforge.net/">FLAC package for
Amiga</a></li>
<li><b>IRIX</b>: <a
href="http://freeware.sgi.com/">FLAC packages for
IRIX</a>.</li>
- <li><b>Solaris 7</b>: <a
href="http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=12841">FLAC
packages for Solaris 7</a></li>
- <li><b>Older versions:</b> <a
href="http://sourceforge.net/project/showfiles.php?group_id=13478">Older
versions available from SourceForge</a></li>
+ <li><b>Solaris 7</b>: <a
href="http://sourceforge.net/projects/flac/files/flac-solaris/">FLAC
packages for Solaris 7</a></li>
+ <li><b>Older versions:</b> <a
href="http://sourceforge.net/projects/flac/files/">Older versions
available from SourceForge</a></li>
</ul>
</li>
</ul>
@@ -141,7 +141,7 @@
-->
<li><a
href="http://getsongbird.com/desktop/">Songbird</a>, <a
href="http://www.vuplayer.com/vuplayer.php">VUPlayer</a>,
<a href="http://www.winamp.com/">Winamp</a>, <a
href="http://xbmc.org/download/">XBMC</a></li>
<li>DirectShow: <a
href="http://www.xiph.org/dshow/">Xiph's OpenCodec</a>
for encoding to/decoding from FLAC (as well as Ogg
Vorbis/Speex/Theora)</li>
- <li><u>Windows Media Player</u>, using <a
href="www.xiph.org/dshow/">Xiph's OpenCodec</a> for
playing and <a
href="http://bmproductions.fixnum.org/index.htm?http://bmproductions.fixnum.org/wmptagplus/">WMP
Tag Support Extender</a> for tagging</li>
+ <li><u>Windows Media Player</u>, using <a
href="http://www.xiph.org/dshow/">Xiph's OpenCodec</a>
for playing and <a
href="http://bmproductions.fixnum.org/index.htm?http://bmproductions.fixnum.org/wmptagplus/">WMP
Tag Support Extender</a> for tagging</li>
<li><u>iTunes</u>, using <a
href="http://www.xiph.org/quicktime/">XiphQT</a> (only Ogg
FLAC)</li>
<li><a
href="http://www.vuplayer.com/audition.php">plugin for Adobe
Audition</a> (alternate plugin <a
href="http://www.hydrogenaudio.org/forums/index.php?showtopic=20145">here</a>)</li>
</ul>
@@ -157,7 +157,7 @@
<li>
<a
name="extras_players_unix"><b>Unix</b></a>
<ul>
- <li><a
href="http://alsaplayer.org/">AlsaPlayer</a>, <a
href="http://www.mplayerhq.hu/">MPlayer</a>, <a
href="http://muine.gooeylinux.org/">Muine</a>, <a
href="http://xine.sourceforge.net/">Xine</a>, <a
href="http://www.amb.org/xmcd/">xmcd</a></li>
+ <li><a
href="http://alsaplayer.sf.net/">AlsaPlayer</a>, <a
href="http://www.mplayerhq.hu/">MPlayer</a>, <a
href="http://muine.gooeylinux.org/">Muine</a>, <a
href="http://xine.sourceforge.net/">Xine</a>, <a
href="http://www.amb.org/xmcd/">xmcd</a></li>
</ul>
</li>
diff --git a/faq.html b/faq.html
index 3380684..2737040 100644
--- a/faq.html
+++ b/faq.html
@@ -218,7 +218,7 @@
<br />
"Native" FLAC is the compressed FLAC data stored in a very
minimalist container, designed to be very efficient at storing single audio
streams.<br />
<br />
- Ogg FLAC is the compressed FLAC data stored in an <a
href="http://xiph.org/ogg/vorbis/doc/oggstream.html">Ogg
container</a>. Ogg is a much more powerful transport layer that enables
mixing several kinds of different streams (audio, data, metadata, etc). The
overhead is slightly higher than with native FLAC.<br />
+ Ogg FLAC is the compressed FLAC data stored in an <a
href="http://xiph.org/vorbis/doc/oggstream.html">Ogg
container</a>. Ogg is a much more powerful transport layer that enables
mixing several kinds of different streams (audio, data, metadata, etc). The
overhead is slightly higher than with native FLAC.<br />
<br />
In either case, the compressed FLAC data is the same and one can be converted
to the other without re-encoding.<br />
<br />
diff --git a/features.html b/features.html
index a1b9e38..bfd39c7 100644
--- a/features.html
+++ b/features.html
@@ -88,7 +88,7 @@
What FLAC is <b>not</b>:
<ul>
<li>
- Lossy. FLAC is intended for lossless compression only, as there are many
good lossy formats already, such as <a
href="http://www.xiph.org/ogg/vorbis/index.html">Vorbis</a>,
<a href="http://www.musepack.net/">MPC</a>, and <a
href="http://www.mp3-tech.org/">MP3</a> (see <a
href="http://www.mp3dev.org/mp3/">LAME</a> for an excellent
open-source implementation).
+ Lossy. FLAC is intended for lossless compression only, as there are many
good lossy formats already, such as <a
href="http://www.xiph.org/vorbis/">Vorbis</a>, <a
href="http://www.musepack.net/">MPC</a>, and <a
href="http://www.mp3-tech.org/">MP3</a> (see <a
href="http://lame.sourceforge.net/">LAME</a> for an excellent
open-source implementation).
</li>
<li>
DRM. There is no intention to add any copy prevention methods. Of course,
we can't stop someone from encrypting a FLAC stream in another container
(e.g. the way Apple encrypts AAC in MP4 with FairPlay), that is the choice of
the user.
diff --git a/feeds/feed.xml b/feeds/feed.xml
index 71a0ac9..5861e2e 100644
--- a/feeds/feed.xml
+++ b/feeds/feed.xml
@@ -95,6 +95,14 @@
</item>
<item>
+ <title>Cubase now supports FLAC</title>
+ <description>With the release of version 6.5, Cubase now supports
exporting to FLAC</description>
+
<link>http://www.steinberg.net/en/company/press/archive/2012/cubase_65_and_cubase_artist_65.html</link>
+ <pubDate>Thu, 01 Mar 2012 21:32:00 +0200</pubDate>
+ <guid>http://flac.sourceforge.net/news.html#20120230</guid>
+ </item>
+
+ <item>
<title>FLAC development moved to Xiph.org</title>
<description>Develoment of FLAC has been moved from Sourceforge to
Xiph.org. For more information, see the linked mail</description>
<link>http://lists.xiph.org/pipermail/flac-dev/2012-February/003083.html</link>
diff --git a/format.html b/format.html
index fe207e4..e64e86a 100644
--- a/format.html
+++ b/format.html
@@ -142,7 +142,7 @@
<a href="http://svr-www.eng.cam.ac.uk/~ajr/">A. J.
Robinson</a> for his work on <a
href="http://svr-www.eng.cam.ac.uk/reports/abstracts/robinson_tr156.html">Shorten</a>;
his paper is a good starting point on some of the basic methods used by FLAC.
FLAC trivially extends and improves the fixed predictors, LPC coefficient
quantization, and Rice coding used in Shorten.
</li>
<li>
- <a href="http://commsci.usc.edu/faculty/golomb.html">S. W.
Golomb</a> and Robert F. Rice; their universal codes are used by
FLAC's entropy coder.
+ <a href="http://csi.usc.edu/faculty/golomb.html">S. W.
Golomb</a> and Robert F. Rice; their universal codes are used by
FLAC's entropy coder.
</li>
<li>
N. Levinson and J. Durbin; the reference encoder uses an algorithm
developed and refined by them for determining the LPC coefficients from the
autocorrelation coefficients.
@@ -234,10 +234,10 @@
<b>Constant</b>. This predictor is used whenever the subblock
is pure DC ("digital silence"), i.e. a constant value throughout. The
signal is run-length encoded and added to the stream.
</li>
<li>
- <b>Fixed linear predictor</b>. FLAC uses a class of
computationally-efficient fixed linear predictors (for a good description, see
<a
href="http://www.hpl.hp.com/techreports/1999/HPL-1999-144.pdf">audiopak</a>
and <a
href="http://svr-www.eng.cam.ac.uk/~ajr/GroupPubs/Robinson94-tr156/index.html">shorten</a>).
FLAC adds a fourth-order predictor to the zero-to-third-order predictors used by
Shorten. Since the predictors are fixed, the predictor order is the only
parameter that needs to be stored in the compressed stream. The error signal is
then passed to the residual coder.
+ <b>Fixed linear predictor</b>. FLAC uses a class of
computationally-efficient fixed linear predictors (for a good description, see
<a
href="http://www.hpl.hp.com/techreports/1999/HPL-1999-144.pdf">audiopak</a>
and <a
href="http://svr-www.eng.cam.ac.uk/reports/abstracts/robinson_tr156.html">shorten</a>).
FLAC adds a fourth-order predictor to the zero-to-third-order predictors used by
Shorten. Since the predictors are fixed, the predictor order is the only
parameter that needs to be stored in the compressed stream. The error signal is
then passed to the residual coder.
</li>
<li>
- <b>FIR Linear prediction</b>. For more accurate modeling (at a
cost of slower encoding), FLAC supports up to 32nd order FIR linear prediction
(again, for information on linear prediction, see <a
href="http://www.hpl.hp.com/techreports/1999/HPL-1999-144.pdf">audiopak</a>
and <a
href="http://svr-www.eng.cam.ac.uk/~ajr/GroupPubs/Robinson94-tr156/index.html">shorten</a>).
The reference encoder uses the Levinson-Durbin method for calculating the LPC
coefficients from the autocorrelation coefficients, and the coefficients are
quantized before computing the residual. Whereas encoders such as Shorten used
a fixed quantization for the entire input, FLAC allows the quantized coefficient
precision to vary from subframe to subframe. The FLAC reference encoder
estimates the optimal precision to use based on the block size and dynamic range
of the original signal.
+ <b>FIR Linear prediction</b>. For more accurate modeling (at a
cost of slower encoding), FLAC supports up to 32nd order FIR linear prediction
(again, for information on linear prediction, see <a
href="http://www.hpl.hp.com/techreports/1999/HPL-1999-144.pdf">audiopak</a>
and <a
href="http://svr-www.eng.cam.ac.uk/reports/abstracts/robinson_tr156.html">shorten</a>).
The reference encoder uses the Levinson-Durbin method for calculating the LPC
coefficients from the autocorrelation coefficients, and the coefficients are
quantized before computing the residual. Whereas encoders such as Shorten used
a fixed quantization for the entire input, FLAC allows the quantized coefficient
precision to vary from subframe to subframe. The FLAC reference encoder
estimates the optimal precision to use based on the block size and dynamic range
of the original signal.
</li>
</ul>
<a name="residualcoding"><font
size="+1"><b><u>Residual
Coding</u></b></font></a><br />
@@ -266,7 +266,7 @@
<li><a
name="def_SEEKTABLE"><b>SEEKTABLE</b></a>: This
is an optional block for storing seek points. It is possible to seek to any
given sample in a FLAC stream without a seek table, but the delay can be
unpredictable since the bitrate may vary widely within a stream. By adding seek
points to a stream, this delay can be significantly reduced. Each seek point
takes 18 bytes, so 1% resolution within a stream adds less than 2k. There can
be only one SEEKTABLE in a stream, but the table can have any number of seek
points. There is also a special 'placeholder' seekpoint which will be
ignored by decoders but which can be used to reserve space for future seek point
insertion.</li>
<li><a
name="def_VORBIS_COMMENT"><b>VORBIS_COMMENT</b></a>:
This block is for storing a list of human-readable name/value pairs. Values are
encoded using UTF-8. It is an implementation of the <a
href="http://xiph.org/vorbis/doc/v-comment.html">Vorbis comment
specification</a> (without the framing bit). This is the only officially
supported tagging mechanism in FLAC. There may be only one VORBIS_COMMENT block
in a stream. In some external documentation, Vorbis comments are called FLAC
tags to lessen confusion.</li>
<li><a
name="def_CUESHEET"><b>CUESHEET</b></a>: This
block is for storing various information that can be used in a cue sheet. It
supports track and index points, compatible with Red Book CD digital audio
discs, as well as other CD-DA metadata such as media catalog number and track
ISRCs. The CUESHEET block is especially useful for backing up CD-DA discs, but
it can be used as a general purpose cueing mechanism for playback.</li>
- <li><a
name="def_PICTURE"><b>PICTURE</b></a>: This block
is for storing pictures associated with the file, most commonly cover art from
CDs. There may be more than one PICTURE block in a file. The picture format is
similar to the <a
href="http://www.id3.org/id3v2.4.0-frames.txt">APIC frame in
ID3v2</a>. The PICTURE block has a type, MIME type, and UTF-8 description
like ID3v2, and supports external linking via URL (though this is discouraged).
The differences are that there is no uniqueness constraint on the description
field, and the MIME type is mandatory. The FLAC PICTURE block also includes the
resolution, color depth, and palette size so that the client can search for a
suitable picture without having to scan them all.</li>
+ <li><a
name="def_PICTURE"><b>PICTURE</b></a>: This block
is for storing pictures associated with the file, most commonly cover art from
CDs. There may be more than one PICTURE block in a file. The picture format is
similar to the <a
href="http://www.id3.org/id3v2.4.0-frames">APIC frame in
ID3v2</a>. The PICTURE block has a type, MIME type, and UTF-8 description
like ID3v2, and supports external linking via URL (though this is discouraged).
The differences are that there is no uniqueness constraint on the description
field, and the MIME type is mandatory. The FLAC PICTURE block also includes the
resolution, color depth, and palette size so that the client can search for a
suitable picture without having to scan them all.</li>
</ul>
</li>
<li>
diff --git a/ogg_mapping.html b/ogg_mapping.html
index 2e2eb93..2b81ca2 100644
--- a/ogg_mapping.html
+++ b/ogg_mapping.html
@@ -45,7 +45,7 @@
</div>
<div class="box_header"></div>
<div class="box_body">
- This page specifies the way in which compressed FLAC data is encapsulated in
an Ogg transport layer. It assumes basic knowledge of the <a
href="format.html">FLAC format</a> and <a
href="http://www.xiph.org/ogg/vorbis/doc/oggstream.html">Ogg
structure</a> and <a
href="http://www.xiph.org/ogg/vorbis/doc/framing.html">framing</a>.<br
/>
+ This page specifies the way in which compressed FLAC data is encapsulated in
an Ogg transport layer. It assumes basic knowledge of the <a
href="format.html">FLAC format</a> and <a
href="http://xiph.org/vorbis/doc/oggstream.html">Ogg
structure</a> and <a
href="http://xiph.org/vorbis/doc/framing.html">framing</a>.<br
/>
<br />
The original FLAC format includes a very thin transport system. This system
of compressed FLAC audio data mixed with a thin transport has come to be known
as 'native FLAC'. The transport consists of audio frame headers and
footers which contain synchronization patterns, timecodes, and checksums (but
notably not frame lengths), and a metadata system. It is very lightweight and
does not support more elaborate transport mechanisms such as multiple logical
streams, but it has served its purpose well.<br />
<br />
@@ -96,7 +96,7 @@
FLAC packets may span page boundaries.
</li>
<li>
- The granule position of pages containing FLAC audio follows the same
semantics as that for Ogg-encapsulated Vorbis as described <a
href="http://www.xiph.org/ogg/vorbis/doc/vorbis-ogg.html">here</a>.
+ The granule position of pages containing FLAC audio follows the same
semantics as that for Ogg-encapsulated Vorbis as described <a
href="http://xiph.org/vorbis/doc/Vorbis_I_spec.html#x1-126000A">here</a>.
</li>
<li>
Redundant fields in the STREAMINFO packet may be set to zero (indicating
"unknown" in native FLAC), which also facilitates single-pass
encoding. These fields are: the minimum and maximum frame sizes, the total
samples count, and the MD5 signature. "Unknown" values for these
fields will not prevent a compliant native FLAC or Ogg FLAC decoder from
decoding the stream.
--
1.7.10.4
--=_JA_1JiMiTSyYOFgV6z7ICg2--
