Looks good. Please do.
On 20.7.2019 0.35, Erik de Castro Lopo wrote:
Erik de Castro Lopo wrote:
Hopefull the final release candidate:
http://mega-nerd.com/tmp/flac-1.3.3rc3.tar.xz
http://mega-nerd.com/tmp/flac-1.3.3rc3.tar.xz.asc
I am assuming everyone was happy with that and that
Version info is now correct.
I noticed there have been some file changes and Visual Studio 2005
project files hadn't been updated. Here's a patch for git version to fix
compilation.
On 15.7.2019 3.32, Erik de Castro Lopo wrote:
Erik de Castro Lopo wrote:
I have a new pre-reelase (with a
Minor changes needed for Visual Studio as the version is defined in the
project files.
Replace 'PACKAGE_VERSION=\1.3.2\' with
'PACKAGE_VERSION=\1.3.3rc1\' in
src/libFLAC/libFLAC_dynamic.vcproj and libFLAC_static.vcproj. And
replace 'PACKAGE_VERSION="1.3.2"' with 'PACKAGE_VERSION="1.3.3rc1"'
On 19.4.2017 11.40, Erik de Castro Lopo wrote:
Hi all,
Anyone know anything about Windows Universal Platform? Someone raised
an issue on github:
https://github.com/xiph/flac/issues/32
The `flac_max`/`flac_min` issue is resolved, but the WUP one is not.
Cheers,
Erik
No experience of
On 2.1.2017 19.02, Erik de Castro Lopo wrote:
Janne Hyvärinen wrote:
Something seems to be wrong with cpu.c CPU detection code. When I
compile things with MSVC all instructions except FMA is detected as
missing, even though they are present in my CPU. That of course results
in awful
Attached is a patch to fix the incorrect CPU feature detection:
On 2.1.2017 16.39, Janne Hyvärinen wrote:
Something seems to be wrong with cpu.c CPU detection code. When I
compile things with MSVC all instructions except FMA is detected as
missing, even though they are present in my CPU
Something seems to be wrong with cpu.c CPU detection code. When I
compile things with MSVC all instructions except FMA is detected as
missing, even though they are present in my CPU. That of course results
in awful performance.
___
flac-dev mailing
Win_utf8 stuff should not be included in libflac since it's only to be
used by the flac.exe frontend. It is not needed by other programs nor
would they benefit from it without doing the extra work of converting
their ansi filenames and functions to utf-8.
--
Janne
On 9.1.2016 5.08, Evan
On 9.3.2015 19:06, lvqcl wrote:
Tristan Matthews wrote:
Hi,
VLC recently migrated to libflac 1.3.1, however we had to revert to
1.3.0 as we had crashes for most FLAC files on the Windows desktop
platform.
More information is available here:
https://trac.videolan.org/vlc/ticket/14104
On 9.3.2015 20:43, lvqcl wrote:
Janne Hyvärinen wrote:
VLC 2.2.0 crashed with exception 0xc005 on the first file I tried.
But libflac itself does not, for example flac.exe and foobar2000 have no
issues.
*Very* interesting.
I suspect that flac.exe and foobar2000 don't use
On 9.12.2014 20:33, Tristan Matthews wrote:
On Tue, Dec 9, 2014 at 1:31 PM, Janne Hyvärinen c...@sci.fi
mailto:c...@sci.fi wrote:
On 25.11.2014 12:14, Miroslav Lichvar wrote:
I think the case with non-zero partition order may need to be fixed
too. For example, with partition
On 9.12.2014 20:31, Janne Hyvärinen wrote:
On 25.11.2014 12:14, Miroslav Lichvar wrote:
I think the case with non-zero partition order may need to be fixed
too. For example, with partition order of 1, predictor order of 16 and
blocksize of 4, the function would return true and blocksize-order
I tested MSYS + MinGW-w64 with GCC 4.9.2 and both 32-bit and 64-bit
versions build without issues.
MSVC 2013 Community version builds 32-bit and 64-bit release and debug
versions without trouble. I don't have older Visual Studios installed
but can make a virtual machine to test if lvqcl or
On 23.11.2014 12:47, Erik de Castro Lopo wrote:
Is that just a matter of renaming them as follows?
mv FLAC.sln FLAC-vs2005.sln
mv FLAC-vs2010.sln FLAC.sln
Yes.
___
flac-dev mailing list
flac-dev@xiph.org
On 23.11.2014 12:44, Erik de Castro Lopo wrote:
lvqcl wrote:
2) Do you plan to release any official binaries (flac, metaflac, maybe
something else)?
Nor had I planned to release binaries.
At least Windows users expect to find official version at
https://xiph.org/flac/download.html. Right
On 27.9.2014 8:54, Erik de Castro Lopo wrote:
Janne Hyvärinen wrote:
Removed buffer size increase. Only tells the filesize to Windows now.
Would it not be possible to do the same when encoding? Of course we
don't know the exact size of the output file, but guessing at 70% of
80% of the input
The previous patch was bugged. The output file wasn't truncated to
correct size and was a bit off from rounding the WAVE/AIFF header to
smallest sector size. And RAW output didn't benefit from the change. And
the existing functions didn't need changes as outputfilename was already
known.
Patch v2, now handles more malformed cases. Original patch was for a
file for which I had a sample from a user but this allows handling some
manually broken test cases.
On 25.9.2014 21:53, Janne Hyvärinen wrote:
Here's a patch to allow flac and metaflac handle files with malformed
I find these Linux user comments about not suffering from fragmentation
curious. I just tested decoding a flac in Fedora 20 and filefrag command
reports the decoded file is in 8 extents. Different name but same thing.
On 26.9.2014 14:08, Erik de Castro Lopo wrote:
Martijn van Beurden wrote:
Removed buffer size increase. Only tells the filesize to Windows now.
On 26.9.2014 14:08, Erik de Castro Lopo wrote:
Martijn van Beurden wrote:
Can you please wrap the setvbuf in _WIN32 IFDEFs too? Currently
memory usage of FLAC decoding is about 1MB, so this patch is
increasing memory usage
Decoding flac files is also prone to producing fragmented files. NTFS
has the ability to completely avoid fragmentation if it is told the file
size before hand, but that would require using special Windows-only
functions. Increasing the write buffer from the default 512 bytes to 10
MB already
Here's a patch that stops the flac binary from writing empty tag fields.
At least in Windows world these come to files by accident. CD extraction
programs pass all possible metadata entries they allow setting in the UI
to flac binary and most of the time most fields are empty when basic
info
Some comments for patch #1, I chose the non-secure versions because they
are faster and produce smaller binary. The functions where these
printings are performed can't in my opinion ever exceed the safety
margin of 32 KB. They print short help and error texts and occasionally
filename, which
Seems that I'm blind. Please excuse me.
On 8.8.2014 21:37, lvqcl wrote:
Janne Hyvärinen wrote:
The break that patch #3 removes is there for a reason. If there is an
error in string conversion there's no point in continuing the operation.
All conversions are discarded if something failed so
On 10.6.2013 22:27, Marcus Johnson wrote:
Also, shouldn't the changelog feature the 4GB windows fix? I remember
reading about that bug fix at the start of 1.3.0, and I for one was
incredibly excited about it.
if nobody remembers it I can try to hunt down that patch on the mail list.
IMO
On 10.6.2013 23:12, Jim wrote:
I thought I saw discussion on the list about adding support for
expanding wildcards on Windows. But I don't see it mentioned in the
changelog. Was this done in this release for either flac.exe or
metaflac.exe?
The feature is there for both of them.
On 3.6.2013 14:24, Miroslav Lichvar wrote:
On Sat, Jun 01, 2013 at 02:33:55PM +0300, Janne Hyvärinen wrote:
On 1.6.2013 14:24, Janne Hyvärinen wrote:
I can confirm. I see 10% speed improvement with that change on Core i7.
Decoding a 1h18min38.133s long test FLAC -8 encoded file takes
On 3.6.2013 14:24, Miroslav Lichvar wrote:
On Sat, Jun 01, 2013 at 02:33:55PM +0300, Janne Hyvärinen wrote:
On 1.6.2013 14:24, Janne Hyvärinen wrote:
I can confirm. I see 10% speed improvement with that change on Core i7.
Decoding a 1h18min38.133s long test FLAC -8 encoded file takes
On 31.5.2013 13:04, Miroslav Lichvar wrote:
On Wed, May 29, 2013 at 04:08:57PM +0200, Martijn van Beurden wrote:
I was surprised to see that the Windows compile on wine actually
outperformed the native Linux one. Probably GCC 4.6 optimized a little
better or something very weird is going on in
On 1.6.2013 14:24, Janne Hyvärinen wrote:
On 31.5.2013 13:04, Miroslav Lichvar wrote:
On Wed, May 29, 2013 at 04:08:57PM +0200, Martijn van Beurden wrote:
I was surprised to see that the Windows compile on wine actually
outperformed the native Linux one. Probably GCC 4.6 optimized a little
On 28.5.2013 21:06, Martijn van Beurden wrote:
On 28-05-13 19:38, Miroslav Lichvar wrote:
I'm always interested in performance tests :).
In that case I hope you saw the previous one, because the decoding
speed-up was credited to be one of your patches, according to some
people over at
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
On 25.5.2013 15:42, Ulrich Klauer wrote:
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
On 22.5.2013 17:03, Felix Homann wrote:
Sorry that it took so long to reply. As mentioned in an earlier mail
my first bisect session wasn't accurate. I've done a new one:
Here's my patch suggestion but I'm no Android guy.
diff --git a/src/flac/utils.c b/src/flac/utils.c
index
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?
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
I uploaded Windows binaries for willing testers at
http://www.saunalahti.fi/~cse/temp/flac-1.3pre4-win32.zip .
I have been using the git version for my own encodes for a while now
without any issues.
___
flac-dev mailing list
flac-dev@xiph.org
On 24.4.2013 15:42, Erik de Castro Lopo wrote:
Janne Hyvärinen wrote:
+#define PPR if(filename) if(raw) printf(%s:,filename); else
flac_printf(%s:,filename);
Are you sure about that line?
GCC complains about an ambiguous 'else'. It definitely needs some
curly braces somewhere
Hopefully the last patch from me to UTF-8 issues.
Metaflac can now print all console supported characters from tags on the
screen. It also fixes metaflac to be able to import its own exports back
without non-ascii characters getting mutilated. And --no-utf8-convert
now works properly with
On 21.4.2013 10:25, Erik de Castro Lopo wrote:
Janne Hyvärinen wrote:
Sorry for spamming but I noticed one more display glitch while doing
further testing. It could leave old status messages at the end of the
line while printing status messages if initial status fit on one line
and new status
I have been doing some heavy testing with the new FLAC version, and I
found that CreateFile function in grabbag had been left out of UTF-8
treatment at some point. This causes re-encoding an existing flac to the
same name to break the file if it contains non-ascii characters.
Attached patch
Small change to metaflac hexdump function. Changed so utf-8 decoding is
only used for filename printing and changed hex output printing to not
rely only on isprint. That function seems to return true for tabulator
control character under Windows when application isn't using C-locale.
At least
On 20.4.2013 17:35, Janne Hyvärinen wrote:
Small change to metaflac hexdump function. Changed so utf-8 decoding
is only used for filename printing and changed hex output printing to
not rely only on isprint. That function seems to return true for
tabulator control character under Windows
On 8.4.2013 21:38, Janne Hyvärinen wrote:
Friendly people on Hydrogenaudio found some bugs with the Unicode
printing code, so I was forced to make adjustments.
While doing testing I noticed that long filenames cause printing bugs
on Linux too. If line length on status printing exceeded
On 2.4.2013 12:57, Erik de Castro Lopo wrote:
I noticed compat.h patch didn't make it into git. I know it may not be
perfect patch but unistd.h is in two different #ifdef checks. First one
is fine when it's excluded on _WIN32 but second check gives is for
everyone if __CYGWIN__ or __EMX__ isn't
On 1.4.2013 13:40, Erik de Castro Lopo wrote:
I need people to test this with MSVC (I may have broken something)
and with MinGW (I can cross-compile but I can't run the tests).
Please report back successes and failures (hopefully with patches).
Cheers,
Erik
I ran the testset with my 32-bit
On 1.4.2013 22:37, Erik de Castro Lopo wrote:
Janne Hyvärinen wrote:
Zip with random patches:
flac_mac: fixes some missing parameters from safe string handling
changes in flac_mac's main.c
flac_mac_project: adds flac's include dir for the project so new
functions can be found
progress_display
On 1.4.2013 15:29, LRN wrote:
That's a valid point.
Alternative approach (something i saw in libxml2 recently) is to make
UTF-8-to-UTF-16 conversion a bit smarter:
First try the conversion, assuming the string to be UTF-8-encoded.
If that fails, assume the string is in native encoding, and run
On 19.3.2013 15:49, JonY wrote:
On 3/19/2013 19:59, Janne Hyvärinen wrote:
On 18.3.2013 12:25, Erik de Castro Lopo wrote:
JonY wrote:
Before anyone does anything, see __wgetmainargs
http://msdn.microsoft.com/en-us/library/ff770599.aspx.
It can expand wildcards. Since it already provides
On 18.3.2013 11:35, JonY wrote:
Before anyone does anything, see __wgetmainargs
http://msdn.microsoft.com/en-us/library/ff770599.aspx.
It can expand wildcards. Since it already provides argc/argv/env, it is
more a less a drop-in replacement for the main() arguments.
MSVC also comes with
On 18.3.2013 15:17, JonY wrote:
On 3/18/2013 19:34, LRN wrote:
On 18.03.2013 13:35, JonY wrote:
Before anyone does anything, see __wgetmainargs
http://msdn.microsoft.com/en-us/library/ff770599.aspx.
It can expand wildcards. Since it already provides argc/argv/env,
it is more a less a
On 11.3.2013 21:21, Erik de Castro Lopo wrote:
Error9error LNK2001: unresolved external symbol
_safe_malloc_mul_2op_
G:\Programming\flac-1.3.0pre2\src\flac\utf8_static.lib(utf8.obj) flac
Error10error LNK1120: 9 unresolved externals
On 11.3.2013 13:05, Erik de Castro Lopo wrote:
It includes Ben Allison's MSVC changes and JonY's MinGW changes with
some tweaks to make both environments happy.
Please don't do that. Adding bits of other patches makes it more
difficult to evaluate and review this patch which is already
53 matches
Mail list logo
