similar to: flac-dev Digest, Vol 101, Issue 24

Hi all, I have tagged 1.3.0pre4 in git and provided a tarball here: http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz I have built and tested the git tree on: linux-x86_64 openbsd5-i386 freebsd5-i386 as well as successfully cross compiling from Linux to 32 and 64 bit MinGW. As far as I am concerned, the only thing left to do for this release is to update the

On 28-04-13 13:23, LRN wrote: > On 28.04.2013 13:38, Erik de Castro Lopo wrote: >> I have tagged 1.3.0pre4 in git and provided a tarball here: >> >> http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz >> >> I have built and tested the git tree on: >> >> linux-x86_64 openbsd5-i386 freebsd5-i386 > i686-w64-mingw32 - builds correctly,

I successfully compiled 1.3.0pre4 on MacOS X 10.8 and the tests succeeded. My configuration is Configuration summary : FLAC version : ........................ 1.3.0pre4 Host CPU : ............................ x86_64 Host Vendor : ......................... apple Host OS : ............................. darwin12.3.0 Compiler is GCC : ..................... yes GCC

Ralph, for Mac OS you should download either the Unarchiver which is free, or Entrophy which is what I use, but it costs like $15 I believe, both support decompressing .7z and Entrophy supports compressing TO .7z On Mon, May 6, 2013 at 3:00 PM, <flac-dev-request at xiph.org> wrote: > Send flac-dev mailing list submissions to > flac-dev at xiph.org > > To subscribe or

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

Well, I'm bored, and I hope I'm not getting in the way of anyone, but I was like hell might as well try to make a new Xcode project, although I am using 10.8 with the latest xcode, so I'd have to manually remove that, but there is one serious concern, and that's that header files are being called from 1 directory up from where they are, for example: "share/compat.h"

On 25.5.2013 10:54, Erik de Castro Lopo wrote: > Robert Kausch wrote: > >> 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: >>

It's not that hard to repackage it, is it? Here you go: www.icer.nl/misc_stuff/flac.xcodeproj .zip On 06-05-13 23:37, Marcus Johnson wrote: > Ralph, for Mac OS you should download either the Unarchiver which is > free, or Entrophy which is what I use, but it costs like $15 I > believe, both support decompressing .7z and Entrophy supports > compressing TO .7z > > > On

On 04/28/13 02:38 am, Erik de Castro Lopo wrote: > Hi all, > > I have tagged 1.3.0pre4 in git and provided a tarball here: > > http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz On OS/2 compile dies here, CC win_utf8_io/win_utf8_io.lo win_utf8_io/win_utf8_io.c:13:75: error: windows.h: No such file or directory ... with lots of more errors. The problem is

Robert Kausch wrote: > 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

Janne Hyv?rinen wrote: > On 25.5.2013 10:54, Erik de Castro Lopo wrote: >> Robert Kausch wrote: >>> I tried 1.3.0pre4 with ICL on Windows and found some issues. >>> 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.

Hi all, Sorry for bringing this up this short before the release, but I noticed something rather strange. I was doing some more exotic checks on the last pre-release when I tried test_streams.sh with FLAC 1.3.0 encoding and an older version (1.1.0 or something like that) decoding. This failed for 24-bit samples and I wondered why. After quite some tests and hex-editors, I found out this is

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

JonY wrote: > How about just forgetting about base XP and require at least SP2 or some > such? Alternatively, use win32api underneath instead, eg > CreateFileW/SetFilePointer. This requires replacing _all_ of the FILE I/O, not just these two functions, which is a lot more work to no clear advantage. The _lseeki64 implementation uses SetFilePointer internally, but doing that directly

On 5.5.2013 18:02, Timothy B. Terriberry wrote: > > Instead I've attached a patch that uses fgetpos/fsetpos. This is > totally untested (I haven't even checked it compiles), but the idea > should work. > You people do realize these hacks would only be required for 10+ year old obsolete compilers?

Timothy B. Terriberry wrote: > Instead I've attached a patch that uses fgetpos/fsetpos. This is > totally untested (I haven't even checked it compiles), but the idea > should work. MSDN says "The pos value is stored in an internal format and is intended for use only by *fgetpos* and *fsetpos*." (http://msdn.microsoft.com/en-us/library/70hdhh4t%28v=vs.80%29.aspx), so

Janne Hyv?rinen wrote: > Oldest Visual Studio supported by FLAC 1.3 is Visual Studio 2005. FLAC > is also configured to be compiled with static linking, so no external > dependencies hinder its function. Ok. Thanks for pointing this out! I use a custom build setup and link dynamically against msvcrt.dll. That's why I came across that problem and didn't realize that it would not

A few comments. 1) MSVCRT.DLL hasn't been used in ages. Each version of visual studio has its own C Runtime Library version, with a naming convention of msvcr##.dll. It's safe to use _fseeki64 and _ftelli64. Leave it up to the developer-user of FLAC to determine whether to statically link or dynamically link. 2) Yes, the "copy" flag in the Metadata API is broken. The APIs

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

On 6.5.2013 0:43, Timothy B. Terriberry wrote: > Janne Hyv?rinen wrote: >> You people do realize these hacks would only be required for 10+ year >> old obsolete compilers? > No, they're required for easy distribution on 12 year old OSes (which, > last I saw, make up almost 40% of Firefox's desktop userbase, and likely > will continue to for some time). > What