1) changelog.html
"Add ability to handle utf8 filenames on Windows (large set of patches from
Janne Hyv?rinen)"
AFAIK Windows internally uses UTF-16LE, not UTF-8. IMHO it's better to use
a general word 'Unicode' instead of 'utf8'.
2) documentation_bugs.html
"The following are major known bugs in the current (1.2.1) release:"
1.2.1 is not the current release. And IIRC the first issue (--replay-gain but no
--padding/-P)
was fixed shortly after the 1.2.1 release.
3) documentation_tasks.html
"dbPowerAMP Audio Player" - dead link; the program was removed from
dBpa website.
4) documentation_tools_plugins.html:
"If you have an older version of Winamp, our plugin is still available
in the FLAC Installer for Windows [http://cyberial.com/flacinstaller.asp]"
The link is dead. Old in_flac plugin can be downloaded from
http://sourceforge.net/projects/flac/files/flac-win/flac-1.2.1-win/flac-1.2.1-win.zip/download
5) documentation_tools_flac.html:
--no-escape-coding option is mentioned; there's no such option now.
6) documentation_tools_flac.html, documentation_tools_metaflac.html
Only decimal point is used in all examples, and it doesn't work on locales
that use decimal comma (example: --until=1:23.45 should be --until=1:23,45
with these locales, etc.) IMHO locale-dependent behavior should be mentioned
somewhere.
7) download.html
GUI encoding/decoding front-ends:
MacFLAC: mentioned two times.
iTunes-to-FLAC: dead link.
Players:
Songbird: dead link?. New link:
https://sourceforge.net/projects/songbird.mirror/
8) faq.html
a)
"How can I play FLAC in Windows Media Player?"
See this guide.[http://www.losslessaudioblog.com/wmpmce-lossless-guide/]
The link is dead.
There exist Media Foundation FLAC Codec
[http://sourceforge.net/projects/mfflac/] -- Win7 and newer.
Also Xiph.org Directshow Filters -- http://www.xiph.org/dshow/
Also WMP is mentioned in documentation_tasks.html
b)
"How do I set up EAC to rip directly to FLAC?"
AutoFLAC -- new link is http://www.legroom.net/software/autoflac
Omni Encoder -- dead link, dead project.
Mareo -- new link is
http://www.hydrogenaudio.org/forums/index.php?s=&showtopic=59569&view=findpost&p=803351
c)
"Why don't Unicode file names work with flac/metaflac on Windows?"
"Why don't wildcards for file names like *.flac or *.wav work with
flac/metaflac on Windows?"
Obsolete since 1.3.0.
d)
"I compressed a file to FLAC with verify on, and flac said "Verify
FAILED!" Why?"
Memtest86+[http://www.memtest86.org/] -- dead link. New link is
http://www.memtest.org/
e)
"and one thing many (all?) of these systems have in common is an ASUS
motherboard (A7V133 or P3V4X)"
Interesting part of computer history, but VERY outdated information.
Should be removed as obsolete, IMHO.
op 19-06-14 21:16, lvqcl schreef:> 2) documentation_bugs.html > "The following are major known bugs in the current (1.2.1) release:" > > 1.2.1 is not the current release. And IIRC the first issue (--replay-gain but no --padding/-P) > was fixed shortly after the 1.2.1 release.Okay, I just checked this, and it seems the replaygain-padding issue has not been resolved yet. Furthermore, I discovered another bug checking the OGG seektable bug that is mentioned in documentation_bugs.html, when encoding to OGG (with flac --ogg somefile.wav) the progress indication is broken. I can't remember this was the case with FLAC 1.2.1
Martijn van Beurden wrote:> op 19-06-14 21:16, lvqcl schreef: >> 2) documentation_bugs.html >> "The following are major known bugs in the current (1.2.1) release:" >> >> 1.2.1 is not the current release. And IIRC the first issue (--replay-gain but no --padding/-P) >> was fixed shortly after the 1.2.1 release. > > Okay, I just checked this, and it seems the replaygain-padding > issue has not been resolved yet.It was mentioned in the changelog <http://xiph.org/flac/changelog.html> "Fixed bug where using --replay-gain without any padding option caused only a small PADDING block to be created (SF #1760790)" but it seems that you are right: <http://sourceforge.net/p/flac/bugs/282/> -- there are fixed in FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH that were not transferred into the main branch: http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/libFLAC/stream_decoder.c?r1=1.147&r2=1.147.2.1&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/libFLAC/stream_decoder.c?r1=1.147.2.1&r2=1.147.2.2&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/flac/encode.c?r1=1.194&r2=1.194.2.1&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH http://flac.cvs.sourceforge.net/viewvc/flac/flac/src/flac/main.c?r1=1.169&r2=1.169.2.1&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH http://flac.cvs.sourceforge.net/viewvc/flac/flac/README?r1=1.85&r2=1.85.2.1&pathrev=FLAC_RELEASE_1_2_1_MAINTENANCE_BRANCH
Martijn van Beurden wrote:> Furthermore, I discovered > another bug checking the OGG seektable bug that is mentioned in > documentation_bugs.html, when encoding to OGG (with flac --ogg > somefile.wav) the progress indication is broken. I can't > remember this was the case with FLAC 1.2.1Yes, flac.exe 1.2.1b writes progress info as expected. But I downloaded the sources of flac 1.2.1, built it with MSVS2013 and it fails just as flac 1.3.0. So probably that's because of changes in libogg (I use libogg 1.3.2). There's a code in encoder_progress_callback() in src/flac/encode.c: if(e->total_samples_to_encode > 0 && !((frames_written-1) & e->stats_mask)) print_stats(e); e->stats_mask is 0x7 or 0xf or 0x3f. So every 8 or 16 or 64 of frames_written flac prints progress stats (imho the values of stats_mask should be updated: they're too small for current processors). But with --ogg option, frames_written variable updates differently, so "!((frames_written-1) & e->stats_mask)" is much more rarely equal to true. A possible solution is to replace e->stats_mask with e->old_frames_written and e->stats_frames_interval: if(e->total_samples_to_encode > 0 && frames_written - e->old_frames_written > e->stats_frames_interval) { print_stats(e); e->old_frames_written = frames_written; } Also, encoder_progress_callback() calculates e->compression_ratio even when e->progress == 0.0, so it becomes 1.#INF.