Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4
On 5/5/2013 09:03, Timothy B. Terriberry wrote: > Robert Kausch wrote: >> The _lseeki64 patch probably is a little more controversial. The problem >> is that fseeki64 and ftelli64 are not available in Windows XP - at least >> not without installing extra MSVC runtime libraries. I changed compat.h >> and replaced them with calls to _lseeki64, which was available at least >> back to Windows 98 and thus doesn't impose such compatibility issues. > > _lseeki64 operates on the underlying file handle, and does not interact > well with the buffering in stdio streams. I _think_ you can use this > successfully if you call fflush() beforehand (as this sets FILE::_cnt to > 0 and FILE::_ptr to FILE::_base). By which I mean I read the MSVCRT > source from MSVC6.0 and it appears this is how things work. > How about just forgetting about base XP and require at least SP2 or some such? Alternatively, use win32api underneath instead, eg CreateFileW/SetFilePointer. > That source also includes an fseeki64()/ftelli64(), but they are not > defined in stdio.h. I wonder if just declaring it yourself is good > enough? If not, they get called by fsetpos()/fgetpos() (which _do_ > interact correctly with the buffering in stdio streams), except when > _MAC is defined (which I presume is not common). I don't actually have > XP to test against. Bad, do no declare manually, I had to cleanup some bad code recently that make assumptions about your header declarations. You can try using GetModuleHandle/GetProcAddress instead, but msvcr* versions are a whole different can of worms. signature.asc Description: OpenPGP digital signature ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4
Robert Kausch wrote: > The _lseeki64 patch probably is a little more controversial. The problem > is that fseeki64 and ftelli64 are not available in Windows XP - at least > not without installing extra MSVC runtime libraries. I changed compat.h > and replaced them with calls to _lseeki64, which was available at least > back to Windows 98 and thus doesn't impose such compatibility issues. _lseeki64 operates on the underlying file handle, and does not interact well with the buffering in stdio streams. I _think_ you can use this successfully if you call fflush() beforehand (as this sets FILE::_cnt to 0 and FILE::_ptr to FILE::_base). By which I mean I read the MSVCRT source from MSVC6.0 and it appears this is how things work. That source also includes an fseeki64()/ftelli64(), but they are not defined in stdio.h. I wonder if just declaring it yourself is good enough? If not, they get called by fsetpos()/fgetpos() (which _do_ interact correctly with the buffering in stdio streams), except when _MAC is defined (which I presume is not common). I don't actually have XP to test against. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Change download link on website
Hi, a patch for the website, to point to downloads.xiph.org for source tarballs instead of SourceForge. Ulrich >From 315cb17081907b8290812f3e5552471faef28e7d Mon Sep 17 00:00:00 2001 From: Ulrich Klauer Date: Sat, 4 May 2013 19:46:11 +0200 Subject: [PATCH] Downloads section: link to downloads.xiph.org In downloads.html, link to downloads.xiph.org instead of SourceForge for source tarballs. Also includes a minor language fix in developers.html. --- developers.html |2 +- download.html |2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/developers.html b/developers.html index 149b6b5..87f0a9a 100644 --- a/developers.html +++ b/developers.html @@ -47,7 +47,7 @@ FLAC is an open source project and we are happy to enlist the help of anyone who wants to contribute, or to help with FLAC support in other programs and devices. The preferred method of communication is the http://lists.xiph.org/mailman/listinfo/flac-dev";>developer mailing list (you must subscribe to post). - FLAC is open to third-party developers who want to add support for FLAC into their programs. All the necessary functionality is contained the libFLAC libraries which are licensed under Xiph.org's BSD license. + FLAC is open to third-party developers who want to add support for FLAC into their programs. All the necessary functionality is contained in the libFLAC libraries which are licensed under Xiph.org's BSD license. Some pointers to developer documentation and code: diff --git a/download.html b/download.html index 8355716..3a94bfc 100644 --- a/download.html +++ b/download.html @@ -50,7 +50,7 @@ All source code and binaries are freely available and distributed under http://www.opensource.org/docs/definition.php";>Open Source licenses. The codec libraries are distributed under Xiph.org's BSD license, and the plugins and command-line utilites (flac and metaflac) are distributed under the http://www.opensource.org/licenses/gpl-license.html";>GPL. If you would like to redistribute parts or all of FLAC under different terms, http://lists.xiph.org/mailman/listinfo/flac-dev";>contact the FLAC-dev mailinglist. (For more information, see the license page.) - Source code: http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=12677";>get stable releases from Sourceforge; 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 https://git.xiph.org/?p=flac.git;a%3Dsummary";>Development git repository + Source code: http://downloads.xiph.org/releases/flac/";>tarballs for stable and beta releases; 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 https://git.xiph.org/?p=flac.git;a%3Dsummary";>Development git repository Linux: most distributions have a FLAC package, use the package manager to get FLAC. If not, try http://rpmfind.net/linux/rpm2html/search.php?query=flac";>rpmfind.net or http://packages.debian.org/cgi-bin/search_packages.pl?keywords=flac&searchon=names&subword=1&version=all&release=all";>Debian's packages Windows: http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=12675";>FLAC for Windows (command-line tools only) Mac OS X: http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=32318";>FLAC tools for OS X. The .dmg file is an installer and the .tar.gz file is a tarball. -- 1.7.10.4 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.2.0 backwards-compatibility break not in changelog?
On 04-05-13 14:17, Martijn van Beurden wrote: To *1.2.1 -> libraries* I would add - Added support for encoding the residual coding method introduced in libFLAC 1.2.1 (RESIDUAL_CODING_METHOD_PARTITIONED_RICE2) which will encode 24-bit files more efficiently I meant "introduced in libFLAC 1.2.0" there of course ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[flac-dev] Bug fix and compatibility patches for 1.3.0pre4
Hi all,
I tried 1.3.0pre4 with ICL on Windows and found some issues. Not sure if
this is the right place to submit patches, but someone suggested this on
the apparently dead SourceForge patch tracker.
The first two are quite straight forward:
- The ICL patch fixes a typo in bitmath.h and adds
FLAC__bitwriter_write_zeroes to the external declarations in bitwriter.c.
- The Ogg patch replaces the check for FLAC_API_SUPPORTS_OGG_FLAC in
stream_decoder.c with FLAC__HAS_OGG to fix compilation with Ogg support.
The _lseeki64 patch probably is a little more controversial. The problem
is that fseeki64 and ftelli64 are not available in Windows XP - at least
not without installing extra MSVC runtime libraries. I changed compat.h
and replaced them with calls to _lseeki64, which was available at least
back to Windows 98 and thus doesn't impose such compatibility issues.
However, the patch only represents my quick and dirty solution and
you'll probably like to find a cleaner one. Maybe all calls to fseeko
and ftello should be put in OS specific wrapper functions.
Would love to see those patches in the 1.3.0 release.
Robert
diff -Naur flac-1.3.0pre4/include/share/compat.h
flac-1.3.0pre4-patched/include/share/compat.h
--- flac-1.3.0pre4/include/share/compat.h 2013-04-07 11:02:38 +
+++ flac-1.3.0pre4-patched/include/share/compat.h 2013-05-04 11:59:54
+
@@ -50,8 +50,8 @@
#include /* for off_t */
#define FLAC__off_t __int64 /* use this instead of off_t to fix the 2 GB limit
*/
#if !defined __MINGW32__
-#define fseeko _fseeki64
-#define ftello _ftelli64
+#define fseeko(f, p, o) _lseeki64((f)->_file, (p), (o))
+#define ftello(f) _lseeki64((f)->_file, 0, SEEK_CUR)
#else /* MinGW */
#if !defined(HAVE_FSEEKO)
#define fseeko fseeko64
diff -Naur flac-1.3.0pre4/src/libFLAC/bitwriter.c
flac-1.3.0pre4-patched/src/libFLAC/bitwriter.c
--- flac-1.3.0pre4/src/libFLAC/bitwriter.c 2013-04-07 02:39:36 +
+++ flac-1.3.0pre4-patched/src/libFLAC/bitwriter.c 2013-05-03 13:54:21
+
@@ -857,6 +857,7 @@
* Unfortunately, the Microsoft VS compiler doesn't pick them up externally. To
* fix that we add extern declarations here.
*/
+extern FLAC__bool FLAC__bitwriter_write_zeroes(FLAC__BitWriter *bw, unsigned
bits);
extern FLAC__bool FLAC__bitwriter_write_raw_int32(FLAC__BitWriter *bw,
FLAC__int32 val, unsigned bits);
extern FLAC__bool FLAC__bitwriter_write_raw_uint64(FLAC__BitWriter *bw,
FLAC__uint64 val, unsigned bits);
extern FLAC__bool
FLAC__bitwriter_write_raw_uint32_little_endian(FLAC__BitWriter *bw,
FLAC__uint32 val);
diff -Naur flac-1.3.0pre4/src/libFLAC/include/private/bitmath.h
flac-1.3.0pre4-patched/src/libFLAC/include/private/bitmath.h
--- flac-1.3.0pre4/src/libFLAC/include/private/bitmath.h2013-04-24
05:19:16 +
+++ flac-1.3.0pre4-patched/src/libFLAC/include/private/bitmath.h
2013-05-03 12:07:43 +
@@ -74,7 +74,7 @@
{
/* Never used with input 0 */
#if defined(__INTEL_COMPILER)
-return _bit_scan_reverse(n) ^ 31U;
+return _bit_scan_reverse(v) ^ 31U;
#elif defined(__GNUC__) && (__GNUC__ >= 4 || (__GNUC__ == 3 && __GNUC_MINOR__
>= 4))
/* This will translate either to (bsr ^ 31U), clz , ctlz, cntlz, lzcnt
depending on
* -march= setting or to a software rutine in exotic machines. */
diff -Naur flac-1.3.0pre4/src/libFLAC/stream_decoder.c
flac-1.3.0pre4-patched/src/libFLAC/stream_decoder.c
--- flac-1.3.0pre4/src/libFLAC/stream_decoder.c 2013-04-07 11:02:38 +
+++ flac-1.3.0pre4-patched/src/libFLAC/stream_decoder.c 2013-05-03 13:45:32
+
@@ -55,7 +55,7 @@
/* technically this should be in an "export.c" but this is convenient enough */
-#ifdef FLAC_API_SUPPORTS_OGG_FLAC
+#ifdef FLAC__HAS_OGG
FLAC_API int FLAC_API_SUPPORTS_OGG_FLAC = FLAC__HAS_OGG ;
#else
FLAC_API int FLAC_API_SUPPORTS_OGG_FLAC = 0 ;
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.2.0 backwards-compatibility break not in changelog?
On 04-05-13 12:41, Erik de Castro Lopo wrote: Miroslav Lichvar wrote: On Thu, May 02, 2013 at 09:31:25PM +0200, Martijn van Beurden wrote: I don't know why this isn't on the changelog, but it is probably still a good idea to add it. This only breaks compatibility for 24-bit streams. (So: decoders older than 1.2.0 might not be able to decode 24-bit FLAC files made by libFLAC 1.2.0 or newer) Interesting, I remember there were some problems with 24-bit encoding, but I wasn't sure if/how it was fixed. It seems the encoding support was actually added later in 1.2.1, so there was a short time for adoption of the new decoder. It should be added to the changelog. It's still a bit of a mystery to me what should be added. Clues? In short: FLAC 1.2.0 added the RICE2 residual coding method (http://flac.sourceforge.net/format.html#partitioned_rice2) to the format and the decoder, but this wasn't in the changelog. This breaks forward compatibility for 24-bit files RICE2 was added because when trying to encode a 24-bit file the residual wouldn't fit in the rice partition (sorry if I worded that wrong, I'm not sure of my math there) and the encoder fell back to verbatim frames, which wasn't very efficient. The new rice partition has one bit more for encoding the rice parameter. It /seems/ this only affects 24-bit files, as I haven't seen a RICE2 partition with 16-bit files (not even on noise with --disable-verbatim-subframes) but I don't know whether this is hard coded somewhere or by design. Anyway, I would to the changelog under *1.2.0 -> FLAC format* the following - Added a new residual coding method (RESIDUAL_CODING_METHOD_PARTITIONED_RICE2) to code 24-bit files more efficiently To *1.2.0 -> libraries* I would add - Added support for decoding the new residual coding method (RESIDUAL_CODING_METHOD_PARTITIONED_RICE2) To *1.2.1 -> libraries* I would add - Added support for encoding the residual coding method introduced in libFLAC 1.2.1 (RESIDUAL_CODING_METHOD_PARTITIONED_RICE2) which will encode 24-bit files more efficiently Hope that helps ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
Re: [flac-dev] FLAC 1.2.0 backwards-compatibility break not in changelog?
Miroslav Lichvar wrote: > On Thu, May 02, 2013 at 09:31:25PM +0200, Martijn van Beurden wrote: > > I don't know why this isn't on the changelog, but it is probably still a > > good idea to add it. This only breaks compatibility for 24-bit streams. > > (So: decoders older than 1.2.0 might not be able to decode 24-bit FLAC > > files made by libFLAC 1.2.0 or newer) > > Interesting, I remember there were some problems with 24-bit encoding, > but I wasn't sure if/how it was fixed. It seems the encoding support > was actually added later in 1.2.1, so there was a short time for > adoption of the new decoder. It should be added to the changelog. It's still a bit of a mystery to me what should be added. Clues? Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
