Re: [flac-dev] flac 1.3.0pre2 pre-release

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 d

Re: [flac-dev] flac 1.3.0pre2 pre-release

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 G:\Programming\flac-1.3.0pre2\objs\release\bin\f

Re: [flac-dev] flac 1.3.0pre2 pre-release

On 14.3.2013 9:37, Erik de Castro Lopo wrote: Janne Hyvärinen wrote: The patch was made from the published pre2 version. It missed the MinGW changes that were applied to git version. Patch applied. Thanks. Erik Unfortunately with this commit the LRN's patch from c

[flac-dev] Patch to remove the dead in_flac project from the MSVC solution

Solution file still contained the removed in_flac project causing unnecessary errors on load. --- FLAC.sln.orig Wed Mar 13 18:23:38 2013 +++ FLAC.slnSat Mar 16 19:14:43 2013 @@ -57,14 +57,6 @@ Project("{4cefbc7c-c215-11db-8314-080020 {4cefbc89-c215-11db-8314-0800200c9a6

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

On 18.3.2013 11:35, JonY wrote: Before anyone does anything, see __wgetmainargs . 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 htt

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

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 >>> . >>> It can expand wildcards. Since it already provides argc/argv/env, >>> it is more

Re: [flac-dev] Patch to add Unicode filename support for win32 flac

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/lib

Re: [flac-dev] FLAC deletes file right after encoding bug.

On 24.3.2013 19:46, Marcus Johnson wrote: > I'm using flac 1.3.0pre2 on Windows 8 (not sure which git version, the > exe was on the mailing list a few days ago) and right after I encode a > 24 bit ~2 hour long flac file, to flac with -8 -e -p -V it creats a > temp file called something like .fl

Re: [flac-dev] flac 1.3.0pre3 pre-release

I'm worried about some of the modifications done to the UTF-8 patch. In commit 2199d086921eb37d249cae0731f334556ec6209d #ifdef checks were changed from specific FLAC__STRINGS_IN_UTF8 to generic _WIN32 and the specific defines were later removed in commit 0cd2e9ed6918b782195d0024dd19dcfa39df8f82

Re: [flac-dev] flac 1.3.0pre3 pre-release

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

Re: [flac-dev] flac 1.3.0pre3 pre-release

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 M

Re: [flac-dev] flac 1.3.0pre3 pre-release

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 progre

Re: [flac-dev] Circular preprocessor define with MSVC

On 6.4.2013 23:30, Ulrich Klauer wrote: Hi, in include/share/alloc.h there is this section: #ifndef SIZE_MAX # ifndef SIZE_T_MAX # ifdef _MSC_VER # define SIZE_T_MAX SIZE_MAX # else # error # endif # endif # define SIZE_MAX SIZE_T_MAX #endif So, if we are on MSVC and have neither SIZE_MA

Re: [flac-dev] flac 1.3.0pre3 pre-release

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

Re: [flac-dev] flac 1.3.0pre3 pre-release

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

[flac-dev] One tiny Windows Unicode patch

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 fix

Re: [flac-dev] One tiny Windows Unicode patch

On 20.4.2013 11:23, Janne Hyvärinen wrote: 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

[flac-dev] Metaflac hex dump UTF-8 and locale fix

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 i

Re: [flac-dev] Metaflac hex dump UTF-8 and locale fix

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 cha

Re: [flac-dev] flac 1.3.0pre3 pre-release

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

[flac-dev] Metaflac UTF-8 fixes

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 impor

Re: [flac-dev] Metaflac UTF-8 fixes

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

Re: [flac-dev] Pre-release 1.3.0pre4 (hopefully the last)

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 http://l

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

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 compiler

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

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 almos

Re: [flac-dev] FLAC currently won't compile for Android [bisected]

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 e908706..6f638

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

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 f

Re: [flac-dev] Bug fix and compatibility patches for 1.3.0pre4

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

Re: [flac-dev] Performance checks

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 Hy

Re: [flac-dev] Performance checks

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

Re: [flac-dev] Performance checks

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. P

Re: [flac-dev] Performance checks

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

Re: [flac-dev] Performance checks

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 with

Re: [flac-dev] (no subject)

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. >

Re: [flac-dev] FLAC 1.3.0 released

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.

Re: [flac-dev] MSVS: debug flac.exe uses release libogg_static.lib

On 2.10.2013 20:27, lvqcl wrote: > Ralph Giles wrote: > >> The way we've been doing the Opus stuff is to have the project files >> expect a build in a parallel checkout. so: >> >> c:\dev\flac\FLAC.sln expects to find an ogg build in >> c:\dev\ogg\win32\VS2010\ >> >> Not as obvious as having a monol

Re: [flac-dev] [PATCH] for win_utf8_io.c

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 wi

Re: [flac-dev] [PATCH] for win_utf8_io.c

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 conv

[flac-dev] Patch to stop writing empty vorbiscomment fields

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 li

[flac-dev] Disk fragmentation

I have been running a lot of large compression tests to see how well Martijn van Beurden's new presets do and was once again reminded how real the fragmentation problem still is. To have decent speed it's necessary to run multiple encoders in parallel. In my setup FLAC was compressing four file

Re: [flac-dev] [PATCH] apodization for struct CompressionLevels

On 22.9.2014 23:22, lvqcl wrote: > Martijn van Beurden wrote: > >>> Wouldn't "tukey(1/2)" be better? >>> >>> Erik >> 5e-1 is directly parsed by strtod, while 1/2 isn't AFAIK. > Another idea is to write flac_strtod() (and probably local_strtod() too) > function that is able to parse both "0.5" and

[flac-dev] Typo in a metaflac error message

Here's a tiny patch to fix a small typo. diff --git a/src/metaflac/utils.c b/src/metaflac/utils.c index 1ee1535..b945c6a 100644 --- a/src/metaflac/utils.c +++ b/src/metaflac/utils.c @@ -167,7 +167,7 @@ void print_error_with_chain_status(FLAC__Metadata_Chain *chain, const char *form }

[flac-dev] Patch to improve malformed vorbiscomment handling

Here's a patch to allow flac and metaflac handle files with malformed vorbiscomment metadata block. diff --git a/src/libFLAC/metadata_iterators.c b/src/libFLAC/metadata_iterators.c index d50df39..39cb276 100644 --- a/src/libFLAC/metadata_iterators.c +++ b/src/libFLAC/metadata_iterators.c @@ -78,7

[flac-dev] Patch to add buffering to decoding too

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 r

Re: [flac-dev] Patch to add buffering to decoding too

inate NTFS fragmentation. On 25.9.2014 23:01, Janne Hyvärinen wrote: 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

Re: [flac-dev] Patch to improve malformed vorbiscomment handling

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 malf

Re: [flac-dev] Patch to add buffering to decoding too

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: >

Re: [flac-dev] Patch to add buffering to decoding too

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 t

Re: [flac-dev] Patch to improve malformed vorbiscomment handling

On 26.9.2014 15:21, Erik de Castro Lopo wrote: Janne Hyvärinen wrote: 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. Err, I'm getting warning messages on that

Re: [flac-dev] Patch to add buffering to decoding too

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 gues

Re: [flac-dev] Patch to add buffering to decoding too

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. Attach

Re: [flac-dev] [PATCH 5/5]

On 5.10.2014 10:22, Erik de Castro Lopo wrote: > lvqcl wrote: > >> This patch adds two AVX2 files and adds AVX2 support code into >> init_stream_internal_() in stream_encoder.c. > Ste of 5 patches all applied. Thanks > > I did run this on my machine with 4 i5-4440 cores wich accoring to /proc/cpu >

Re: [flac-dev] New release

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 someo

Re: [flac-dev] New release

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 http://lists.xiph.org/mailman/l

Re: [flac-dev] New release

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. Rig

Re: [flac-dev] Two new CVEs against FLAC

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 in > the caller would still underflow. > >

Re: [flac-dev] Two new CVEs against FLAC

On 9.12.2014 20:33, Tristan Matthews wrote: On Tue, Dec 9, 2014 at 1:31 PM, Janne Hyvärinen <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 parti

Re: [flac-dev] Two new CVEs against FLAC

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

Re: [flac-dev] Two new CVEs against FLAC

On 9.12.2014 22:51, lvqcl wrote: Janne Hyvärinen wrote: Can you share samples? It's a 470 MB copyrighted music album. I could but I don't think it's legal. How about sharing the album name (if it's popular enough)? (but then it would be good to post its CUETools ver

Re: [flac-dev] crash on lpc_restore_signal_16_intrin_sse2

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/

Re: [flac-dev] crash on lpc_restore_signal_16_intrin_sse2

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

Re: [flac-dev] Lets do a 1.3.2 release

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 Ramos

Re: [flac-dev] FLAC 1.3.2 has been released

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

Re: [flac-dev] FLAC 1.3.2 has been released

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. That

Re: [flac-dev] FLAC 1.3.2 has been released

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

Re: [flac-dev] Windows Universal Platform?

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 UWP

Re: [flac-dev] Prelease now available

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

Re: [flac-dev] Prelease now available

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 GP

Re: [flac-dev] Prelease now available

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