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 I can release a new version. Cheers, Erik ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 GPG signature) up here: New version: http://mega-nerd.com/tmp/flac-1.3.3rc2.tar.xz http://mega-nerd.com/tmp/flac-1.3.3rc2.tar.xz.asc Erik diff --git a/src/libFLAC/libFLAC_dynamic.vcproj b/src/libFLAC/libFLAC_dynamic.vcproj index 3815c79b..ecddc1e7 100644 --- a/src/libFLAC/libFLAC_dynamic.vcproj +++ b/src/libFLAC/libFLAC_dynamic.vcproj @@ -345,6 +345,10 @@ RelativePath=".\lpc_intrin_sse41.c" > + + @@ -397,6 +401,10 @@ RelativePath=".\stream_encoder_intrin_ssse3.c" > + + diff --git a/src/libFLAC/libFLAC_static.vcproj b/src/libFLAC/libFLAC_static.vcproj index 6b6edf0c..9b6f37d1 100644 --- a/src/libFLAC/libFLAC_static.vcproj +++ b/src/libFLAC/libFLAC_static.vcproj @@ -386,6 +386,10 @@ RelativePath=".\lpc_intrin_sse41.c" > + + @@ -438,6 +442,10 @@ RelativePath=".\stream_encoder_intrin_ssse3.c" > + + ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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"' in src/libFLAC/libFLAC_dynamic.vcxproj and libFLAC_static.vcxproj. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 here but the unicode stuff is only meant for the command line FLAC frontend. It should be excluded entirely on UWP. I found some defines on https://msdn.microsoft.com/en-us/library/mt186162.aspx that should be useful. The Windows UTF8 helper stuff should probably only be included when either none of these new defines are present or only WINAPI_FAMILY_PARTITION(WINAPI_PARTITION_DESKTOP) is defined. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 performance. What Windows version and CPU was this? Erik That shouldn't matter. The __cpuid function was called with feature_id set to 0 so it was only returning manufacturer info. Not the features that were asked. But I'm on Windows 10 and CPU is Core i7-4771. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 of course
results in awful performance.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
diff --git a/src/libFLAC/cpu.c b/src/libFLAC/cpu.c
index b9df19a..808d55d 100644
--- a/src/libFLAC/cpu.c
+++ b/src/libFLAC/cpu.c
@@ -269,9 +269,9 @@ void FLAC__cpu_info_x86(FLAC__uint32 level, FLAC__uint32
*eax, FLAC__uint32 *ebx
__cpuid(cpuinfo, ext);
if((unsigned)cpuinfo[0] >= level) {
#if FLAC__AVX_SUPPORTED
- __cpuidex(cpuinfo, ext, 0); /* for AVX2 detection */
+ __cpuidex(cpuinfo, level, 0); /* for AVX2 detection */
#else
- __cpuid(cpuinfo, ext); /* some old compilers don't support
__cpuidex */
+ __cpuid(cpuinfo, level); /* some old compilers don't support
__cpuidex */
#endif
*eax = cpuinfo[0]; *ebx = cpuinfo[1]; *ecx = cpuinfo[2]; *edx =
cpuinfo[3];
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 wrote: lvqcl wrote: IIRC libFLAC.a built with "./autogen.sh && ./configure && make" contains all functions from win_utf8_io. So I think it's possible to change some Makefile.lite or maybe build/*.mk files so that there will be no need to add -lwin_utf8_io to -lFLAC. Version 2 of my patch attached, which fixes the problem for the Makefile.lite and Visual Studio build systems without moving win_utf8_io.c or touching the Autotools system. -Evan ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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/ticket/14104 Cannot reproduce the crash here. Also I downloaded VLC 2.2.0 (32-bit Windows build) and it also doesn't crash. 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. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 flac.exe and foobar2000 don't use FLAC__lpc_restore_signal_16_intrin_sse2() function at all. This function is not used if NASM is available; FLAC__lpc_restore_signal_asm_ia32_mmx() is used instead. I wonder how to debug this crash... I compiled flac.exe without NASM and verified that FLAC__lpc_restore_signal_16_intrin_sse2 is used. Decoding the same file that made VLC 2.2 crash decoded without issues. Would be nice if VLC was compilable with MSVC and we could use its debugger. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 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 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.
--- a/src/libFLAC/stream_decoder.c
+++ b/src/libFLAC/stream_decoder.c
@@ -2744,7 +2744,7 @@ FLAC__bool
read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigne
if(partition_samples predictor_order) {
send_error_to_client_(decoder,
FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC);
decoder-protected_-state =
FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC;
- return true;
+ return false;
}
}
Thoughts?
This patch breaks seeking in some perfectly valid files. So far I have
received one sample full CD image from a foobar2000 user where a track
is rendered inaccessible because of this. Re-encoding the file
with FLAC
1.2.1 - 1.3.1 with identical settings doesn't remove the seeking
problem.
Either this patch needs to go or it needs to be altered to not prevent
seek sync.
Can you share samples?
It's a 470 MB copyrighted music album. I could but I don't think it's legal.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 would return true and blocksize-order in
the caller would still underflow.
--- a/src/libFLAC/stream_decoder.c
+++ b/src/libFLAC/stream_decoder.c
@@ -2744,7 +2744,7 @@ FLAC__bool
read_residual_partitioned_rice_(FLAC__StreamDecoder *decoder, unsigne
if(partition_samples predictor_order) {
send_error_to_client_(decoder,
FLAC__STREAM_DECODER_ERROR_STATUS_LOST_SYNC);
decoder-protected_-state =
FLAC__STREAM_DECODER_SEARCH_FOR_FRAME_SYNC;
- return true;
+ return false;
}
}
Thoughts?
This patch breaks seeking in some perfectly valid files. So far I have
received one sample full CD image from a foobar2000 user where a track
is rendered inaccessible because of this. Re-encoding the file with FLAC
1.2.1 - 1.3.1 with identical settings doesn't remove the seeking problem.
Either this patch needs to go or it needs to be altered to not prevent
seek sync.
In general I'm against patches that error out at the first sign of
corruption instead of gracefully handling the situation and continuing
from the next good bytes. I think it would be better to let the decoder
continue its work when possible and perform input validation where it's
relevant.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 someone else doesn't have any either. I have one related suggestion. The Windows solution files should be renamed. Right now the old solution file that one is supposed to use on old MSVC versions is called FLAC.sln and the new one is called FLAC-vs2010.sln. I'd like the main file FLAC.sln to be the one that works with all the latest Visual Studios and the old legacy format one be called FLAC-vs2005.sln. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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/listinfo/flac-dev
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. Right now it links to old sourceforge page http://sourceforge.net/projects/flac/files/flac-win/ that only has version 1.2.1. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 guessing at 70% of 80% of the input file size would be correct in most cases? Are there any negative consequences of overestimating like this? Estimating the size too large while other processes are writing to the drive at the same time would leave a gap behind the file. My fear was that writing thousands of files one after another, and many of them leaving these empty spaces, would eventually cause the drive to be sparsely filled resulting in all further large file writes to being spread all around the drive. Underestimating a little would of course not cause this. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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. Attached is a fixed and improved version.
diff --git a/src/flac/decode.c b/src/flac/decode.c
index 5e5e17a..ed7eff8 100644
--- a/src/flac/decode.c
+++ b/src/flac/decode.c
@@ -263,6 +263,23 @@ FLAC__bool DecoderSession_construct(DecoderSession *d,
FLAC__bool is_ogg, FLAC__
void DecoderSession_destroy(DecoderSession *d, FLAC__bool error_occurred)
{
if(0 != d-fout d-fout != stdout) {
+#ifdef _WIN32
+ if(!error_occurred) {
+ FLAC__off_t written_size = ftello(d-fout);
+ if(written_size 0) {
+ HANDLE fh = CreateFile_utf8(d-outfilename,
GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
+ if(fh != INVALID_HANDLE_VALUE) {
+ if(GetFileType(fh) == FILE_TYPE_DISK) {
+ LARGE_INTEGER size;
+ size.QuadPart = written_size;
+ if(SetFilePointerEx(fh, size,
NULL, FILE_CURRENT)) /* correct the file size */
+ SetEndOfFile(fh);
+ }
+ CloseHandle(fh);
+ }
+ }
+ }
+#endif
fclose(d-fout);
if(error_occurred)
flac_unlink(d-outfilename);
@@ -364,6 +381,32 @@ FLAC__bool DecoderSession_process(DecoderSession *d)
}
}
+#ifdef _WIN32
+ if(!d-analysis_mode !d-test_only d-total_samples 0
d-fout != stdout) {
+ HANDLE fh = CreateFile_utf8(d-outfilename,
GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
+ if(fh != INVALID_HANDLE_VALUE) {
+ if (GetFileType(fh) == FILE_TYPE_DISK) {
+ LARGE_INTEGER size;
+ size.QuadPart = d-total_samples * d-channels
* ((d-bps+7)/8);
+ if(d-format != FORMAT_RAW) {
+ size.QuadPart += 512;
+ if(d-foreign_metadata) {
+ size_t i;
+ for(i =
d-format==FORMAT_RF64?2:1; i d-foreign_metadata-num_blocks; i++) {
+ if(i !=
d-foreign_metadata-format_block i != d-foreign_metadata-audio_block)
+ size.QuadPart
+= d-foreign_metadata-blocks[i].size;
+ }
+ }
+ }
+
+ if(SetFilePointerEx(fh, size, NULL,
FILE_CURRENT)) /* tell filesystem the expected filesize to eliminate
fragmentation */
+ SetEndOfFile(fh);
+ }
+ CloseHandle(fh);
+ }
+ }
+#endif
+
/* write the WAVE/AIFF headers if necessary */
if(!d-analysis_mode !d-test_only d-format != FORMAT_RAW) {
if(!write_iff_headers(d-fout, d, d-total_samples)) {
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 malformed
vorbiscomment metadata block.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
diff --git a/src/libFLAC/metadata_iterators.c b/src/libFLAC/metadata_iterators.c
index d50df39..cba864c 100644
--- a/src/libFLAC/metadata_iterators.c
+++ b/src/libFLAC/metadata_iterators.c
@@ -77,8 +77,8 @@ static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_streaminfo_c
static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_padding_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Seek seek_cb, FLAC__StreamMetadata_Padding *block, unsigned
block_length);
static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_application_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_Application *block,
unsigned block_length);
static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_seektable_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_SeekTable *block, unsigned
block_length);
-static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_vorbis_comment_entry_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_VorbisComment_Entry *entry);
-static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_vorbis_comment_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_VorbisComment *block);
+static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_vorbis_comment_entry_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_VorbisComment_Entry *entry,
unsigned max_length);
+static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_vorbis_comment_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__IOCallback_Seek seek_cb,
FLAC__StreamMetadata_VorbisComment *block, unsigned block_length);
static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_cuesheet_track_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_CueSheet_Track *track);
static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_cuesheet_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_CueSheet *block);
static FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_picture_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_Picture *block);
@@ -2091,7 +2091,7 @@ FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_cb_(FLAC__IOHandle
case FLAC__METADATA_TYPE_SEEKTABLE:
return read_metadata_block_data_seektable_cb_(handle,
read_cb, block-data.seek_table, block-length);
case FLAC__METADATA_TYPE_VORBIS_COMMENT:
- return
read_metadata_block_data_vorbis_comment_cb_(handle, read_cb,
block-data.vorbis_comment);
+ return
read_metadata_block_data_vorbis_comment_cb_(handle, read_cb, seek_cb,
block-data.vorbis_comment, block-length);
case FLAC__METADATA_TYPE_CUESHEET:
return read_metadata_block_data_cuesheet_cb_(handle,
read_cb, block-data.cue_sheet);
case FLAC__METADATA_TYPE_PICTURE:
@@ -2189,16 +2189,21 @@ FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_seektable_cb_(FLAC_
return FLAC__METADATA_SIMPLE_ITERATOR_STATUS_OK;
}
-FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_vorbis_comment_entry_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_VorbisComment_Entry *entry)
+FLAC__Metadata_SimpleIteratorStatus
read_metadata_block_data_vorbis_comment_entry_cb_(FLAC__IOHandle handle,
FLAC__IOCallback_Read read_cb, FLAC__StreamMetadata_VorbisComment_Entry *entry,
unsigned max_length)
{
const unsigned entry_length_len =
FLAC__STREAM_METADATA_VORBIS_COMMENT_ENTRY_LENGTH_LEN / 8;
FLAC__byte buffer[4]; /* magic number is asserted below */
FLAC__ASSERT(FLAC__STREAM_METADATA_VORBIS_COMMENT_ENTRY_LENGTH_LEN / 8
== sizeof(buffer));
+ if(max_length entry_length_len) return
FLAC__METADATA_CHAIN_STATUS_BAD_METADATA; else max_length -= entry_length_len;
if(read_cb(buffer, 1, entry_length_len, handle) != entry_length_len)
return FLAC__METADATA_SIMPLE_ITERATOR_STATUS_READ_ERROR;
entry-length = unpack_uint32_little_endian_(buffer, entry_length_len);
+ if(max_length entry-length) {
+ entry-length = 0;
+ return FLAC__METADATA_CHAIN_STATUS_BAD_METADATA;
+ } else max_length -= entry-length;
if(0 != entry-entry
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: 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 tenfold, also for platforms that do not need this. It is a non-problem on my system anyway. +1 Will apply patch when it (and the previous one) are wrapped in Win32 #ifdef or similar. Erik ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 tenfold, also for platforms that do not
need this. It is a non-problem on my system anyway.
+1
Will apply patch when it (and the previous one) are wrapped in
Win32 #ifdef or similar.
Erik
diff --git a/src/flac/decode.c b/src/flac/decode.c
index 5e5e17a..7705107 100644
--- a/src/flac/decode.c
+++ b/src/flac/decode.c
@@ -101,7 +101,7 @@ static FLAC__bool is_big_endian_host_;
static FLAC__bool DecoderSession_construct(DecoderSession *d, FLAC__bool
is_ogg, FLAC__bool use_first_serial_number, long serial_number, FileFormat
format, FLAC__bool treat_warnings_as_errors, FLAC__bool
continue_through_decode_errors, FLAC__bool channel_map_none,
replaygain_synthesis_spec_t replaygain_synthesis_spec, FLAC__bool
analysis_mode, analysis_options aopts, utils__SkipUntilSpecification
*skip_specification, utils__SkipUntilSpecification *until_specification,
utils__CueSpecification *cue_specification, foreign_metadata_t
*foreign_metadata, const char *infilename, const char *outfilename);
static void DecoderSession_destroy(DecoderSession *d, FLAC__bool
error_occurred);
static FLAC__bool DecoderSession_init_decoder(DecoderSession *d, const char
*infilename);
-static FLAC__bool DecoderSession_process(DecoderSession *d);
+static FLAC__bool DecoderSession_process(DecoderSession *d, const char
*outfilename);
static int DecoderSession_finish_ok(DecoderSession *d);
static int DecoderSession_finish_error(DecoderSession *d);
static FLAC__bool
canonicalize_until_specification(utils__SkipUntilSpecification *spec, const
char *inbasefilename, unsigned sample_rate, FLAC__uint64 skip, FLAC__uint64
total_samples_in_input);
@@ -177,7 +177,7 @@ int flac__decode_file(const char *infilename, const char
*outfilename, FLAC__boo
if(!DecoderSession_init_decoder(decoder_session, infilename))
return DecoderSession_finish_error(decoder_session);
- if(!DecoderSession_process(decoder_session))
+ if(!DecoderSession_process(decoder_session, outfilename))
return DecoderSession_finish_error(decoder_session);
return DecoderSession_finish_ok(decoder_session);
@@ -317,7 +317,7 @@ FLAC__bool DecoderSession_init_decoder(DecoderSession
*decoder_session, const ch
return true;
}
-FLAC__bool DecoderSession_process(DecoderSession *d)
+FLAC__bool DecoderSession_process(DecoderSession *d, const char *outfilename)
{
if(!FLAC__stream_decoder_process_until_end_of_metadata(d-decoder)) {
flac__utils_printf(stderr, 2, \n);
@@ -366,6 +366,28 @@ FLAC__bool DecoderSession_process(DecoderSession *d)
/* write the WAVE/AIFF headers if necessary */
if(!d-analysis_mode !d-test_only d-format != FORMAT_RAW) {
+#ifdef _WIN32
+ if(strcmp(outfilename, -) d-total_samples 0) {
+ HANDLE fh = CreateFile_utf8(outfilename,
GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
+ if(fh != INVALID_HANDLE_VALUE) {
+ if (GetFileType(fh) == FILE_TYPE_DISK) {
+ LARGE_INTEGER size;
+ size.QuadPart = d-total_samples *
d-channels * ((d-bps+7)/8) + 512;
+ if(d-foreign_metadata) {
+ size_t i;
+ for(i =
d-format==FORMAT_RF64?2:1; i d-foreign_metadata-num_blocks; i++) {
+ if(i !=
d-foreign_metadata-format_block i != d-foreign_metadata-audio_block)
+ size.QuadPart
+= d-foreign_metadata-blocks[i].size;
+ }
+ }
+
+ if(SetFilePointerEx(fh, size, NULL,
FILE_CURRENT)) /* tell filesystem the expected filesize to eliminate
fragmentation */
+ SetEndOfFile(fh);
+ }
+ CloseHandle(fh);
+ }
+ }
+#endif
if(!write_iff_headers(d-fout, d, d-total_samples)) {
d-abort_flag = true;
return false;
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
[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 reduces the problem tremendously. diff --git a/src/flac/decode.c b/src/flac/decode.c index 5e5e17a..9e9405c 100644 --- a/src/flac/decode.c +++ b/src/flac/decode.c @@ -251,6 +251,7 @@ FLAC__bool DecoderSession_construct(DecoderSession *d, FLAC__bool is_ogg, FLAC__ DecoderSession_destroy(d, /*error_occurred=*/true); return false; } + setvbuf(d-fout, NULL, _IOFBF, 10*1024*1024); /* 10MB output buffer to help reduce disk fragmentation */ } } ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
[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 like artist, album, title, track number and release date are the
only fields that are set.
diff --git a/src/flac/vorbiscomment.c b/src/flac/vorbiscomment.c
index ed9f710..0e99267 100644
--- a/src/flac/vorbiscomment.c
+++ b/src/flac/vorbiscomment.c
@@ -243,7 +243,7 @@ FLAC__bool flac__vorbiscomment_add(FLAC__StreamMetadata
*block, const char *comm
return false;
}
- if(!set_vc_field(block, parsed, dummy, raw, violation)) {
+ if(parsed.field_value_length 0 !set_vc_field(block, parsed,
dummy, raw, violation)) {
free_field(parsed);
return false;
}
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 with APIs is restricted to 260 characters. And you can't feed it longer faulty names either because maximum command line length is much shorter than 32 KB. Patch #2 is good. I was apparently not thinking when writing that. 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 not exiting from the loop is wasted effort. On 8.8.2014 18:18, lvqcl wrote: For better readability the patch is divided by 3 parts. Part #1: for a bit better security replace vsprintf(utmp, format, argptr) with vsnprintf_s(utmp, 32768, _TRUNCATE, format, argptr) Part #2: potential memleak fixed: utf8argv[i] are not freed when utf8argv itself is freed. Part #3: 'if (ret != 0) break;' line seems redundant. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 conversions are discarded if something failed so not exiting from
the loop is wasted effort.
Here is the current code:
ret = 0;
for (i=0; iwargc; i++) {
if ((utf8argv[i] = utf8_from_wchar(wargv[i])) == NULL) {
ret = 1;
break;
}
if (ret != 0) break;
}
I cannot see how the second break can happen.
If utf8argv[i] != NULL then ret == 0; if utf8argv[i] == NULL then the first
break exits the for(i=...) loop.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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. IMO it should have been mentioned and I voiced my opinion about this to Eric on IRC before the official announcement. At least it's mentioned in the news posting on Hydrogenaudio: http://www.hydrogenaudio.org/forums/index.php?showtopic=101082 ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 normal asm optimizations 7.656s (speed: 616,266x realtime) and with that tiny change 6.937s (speed: 680,140x realtime). Thanks for the testing. I noticed a side effect for this change. Encoding got a bit slower at least when md5 checksumming is enabled. That's odd. How much slower was the encoding? Could it be caused by increase in the size of the function (only with -funroll-loops?) and not fitting in the cache during encoding? It might be good to use -funroll-loops only with some files, IIRC it helped most to stream_encoder.c. I neglected to mention that the testing was done with MSVC 2012 and on Windows. I did some futher testing after your mail and noticed that with GCC the encoding speed is unaffected. Decoding speed increase is not as big as with MSVC, only 7% improvement with it. With MSVC the drop in encoding speed with my test file is 0.4%. Other perhaps interesting speed results: MSVC compile with unaltered sources is 1.9% faster than GCC at encoding. GCC decoding is 8% faster than MSVC before the modification and 5.6% after the modification. These results are without changing any compiling options on either compiler. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 normal asm optimizations 7.656s (speed: 616,266x realtime) and with that tiny change 6.937s (speed: 680,140x realtime). Thanks for the testing. I noticed a side effect for this change. Encoding got a bit slower at least when md5 checksumming is enabled. That's odd. How much slower was the encoding? Could it be caused by increase in the size of the function (only with -funroll-loops?) and not fitting in the cache during encoding? It might be good to use -funroll-loops only with some files, IIRC it helped most to stream_encoder.c. I neglected to mention that the testing was done with MSVC 2012 and on Windows. I did some futher testing after your mail and noticed that with GCC the encoding speed is unaffected. Decoding speed increase is not as big as with MSVC, only 7% improvement with it. With MSVC the drop in encoding speed with my test file is 0.4%. Other perhaps interesting speed results: MSVC compile with unaltered sources is 1.9% faster than GCC at encoding. GCC decoding is 8% faster than MSVC before the modification and 5.6% after the modification. These results are without changing any compiling options on either compiler. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 on in wine, I don't know. The assembly optimizations work very well on encoding, but actually slow things down when decoding. The difference is not very large however. In a quick test with a pre 4.8 gcc on a Core 2 CPU I see a small improvement in decoding speed with assembly optimizations turned on, but I think the difference used to be larger. Perhaps the compilers got better or MMX is slower relative to normal code on current CPUs. Disabling the FLAC__bitreader_read_rice_signed_block_asm_ia32_bswap function seems to help a bit. (there is an #if disabling the function with comment OPT: not clearly faster, needs more testing in the src/libFLAC/stream_decoder.c file) Here is the relative decoding speed with -5 and -8: -5 -8 no asm99.0% 97.0% asm 100.0% 100.0% asm (no ia32_bswap) 102.7% 102.7% I think we should drop that assembly function as the C version seems to be faster now. Can anyone confirm this? Thanks, 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 normal asm optimizations 7.656s (speed: 616,266x realtime) and with that tiny change 6.937s (speed: 680,140x realtime). ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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. Probably GCC 4.6 optimized a little better or something very weird is going on in wine, I don't know. The assembly optimizations work very well on encoding, but actually slow things down when decoding. The difference is not very large however. In a quick test with a pre 4.8 gcc on a Core 2 CPU I see a small improvement in decoding speed with assembly optimizations turned on, but I think the difference used to be larger. Perhaps the compilers got better or MMX is slower relative to normal code on current CPUs. Disabling the FLAC__bitreader_read_rice_signed_block_asm_ia32_bswap function seems to help a bit. (there is an #if disabling the function with comment OPT: not clearly faster, needs more testing in the src/libFLAC/stream_decoder.c file) Here is the relative decoding speed with -5 and -8: -5 -8 no asm 99.0% 97.0% asm 100.0% 100.0% asm (no ia32_bswap) 102.7% 102.7% I think we should drop that assembly function as the C version seems to be faster now. Can anyone confirm this? Thanks, 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 normal asm optimizations 7.656s (speed: 616,266x realtime) and with that tiny change 6.937s (speed: 680,140x realtime). I noticed a side effect for this change. Encoding got a bit slower at least when md5 checksumming is enabled. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 HydrogenAudio: http://lists.xiph.org/pipermail/flac-dev/2013-March/003856.html Really, great stuff ;) I think if you are setting CFLAGS you need to include also the optimizations flags, e.g. -m32 -O3 -funroll-loops to match the default CFLAGS. Oh, I thought I was appending flags. Anyway, thanks, that solved the problem. I didn't know compiler flags could make such an enormous difference. It will take me a few hours to rerun the test however. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev On Windows the 32-bit NASM enabled compiles are always fastest. If you can run 32-bit code on your Linux box you should compile with assembly optimizations. ___ 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
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: - 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. Sorry, I've read through this thread and can't figure out what was actually decided and which patch I should be looking at. Clues? Erik None. The functions in use do not prevent the program from working on any operating system. Their usage only requires compiler to have the functions, and all Microsoft Visual C compilers since version 2005 have them. If there is will to support older compilers it should be in some MSVC version dependant macro, so that new compilers don't need hacks. ___ 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
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 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. Sorry, I've read through this thread and can't figure out what was actually decided and which patch I should be looking at. None. I think the first two patches should actually go in. - The second patch absolutely, because it fixes an all-platform regression. (Actually, slightly modified perhaps; or even better, we revert this part to how it was in 1.2.1. Attaching a patch to do that.) - The first patch addresses two different issues. I've split it into two patches (also attached). One of them fixes a mistyped variable name that will obviously cause the Intel compiler to fail. Regarding the other, well, it is certainly consistent with the other external declarations, and if it helps the Intel compiler, why not? Ulrich ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev Ah indeed, I have nothing against those. I should have read all the quoted text. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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..6f6382e 100644
--- a/src/flac/utils.c
+++ b/src/flac/utils.c
@@ -171,13 +171,13 @@ static int console_chars_left;
int get_console_width(void)
{
int width = 80;
-#ifdef _WIN32
+#if defined _WIN32
width = win_get_console_width();
#elif defined __EMX__
-int s[2];
-_scrsize (s);
-width = s[0];
-#else
+ int s[2];
+ _scrsize (s);
+ width = s[0];
+#elif !defined __ANDROID__
struct winsize w;
if (ioctl(STDOUT_FILENO, TIOCGWINSZ, w) != -1) width = w.ws_col;
#endif
___
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
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? ___ 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
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 kind of nonsense is this? You should know that the last Microsoft compiler to create dynamically linked code that used msvcrt.dll was Visual Studio 6.0 from 1998. 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. If you take a look at the following MSDN pages for Visual Studio 2005, you will see that _fseeki64 and _ftelli64 are supported all the way back to Windows 95: http://msdn.microsoft.com/en-us/library/75yw9bf3%28v=vs.80%29.aspx and http://msdn.microsoft.com/en-US/library/0ys3hc0b%28v=vs.80%29.aspx ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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://lists.xiph.org/mailman/listinfo/flac-dev
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 'else'. It definitely needs some
curly braces somewhere there to make the intend explicit.
So it seems, I didn't expect any issues so I didn't test with mingw.
MSVC accepted things fine.
Changing it to #define PPR if(filename) { if(raw) {
printf(%s:,filename); } else { flac_printf(%s:,filename); } }
makes GCC happy.
The extra if (raw) check is there so command like metaflac
--no-utf8-convert --list *.flac file.txt gives nice UTF-8 encoded
text file where both filenames and tags are encoded properly.
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
[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 import and export commands.
I updated my Windows binary archive with these changes for any
interested party to test:
http://www.saunalahti.fi/~cse/temp/flac-1.3pre3-mod.zip
diff --git a/src/metaflac/operations.c b/src/metaflac/operations.c
index e01fa5c..529b0e5 100644
--- a/src/metaflac/operations.c
+++ b/src/metaflac/operations.c
@@ -551,7 +551,7 @@ void write_metadata(const char *filename,
FLAC__StreamMetadata *block, unsigned
unsigned i, j;
/*@@@ yuck, should do this with a varargs function or something: */
-#define PPR if(filename)flac_printf(%s:,filename);
+#define PPR if(filename) if(raw) printf(%s:,filename); else
flac_printf(%s:,filename);
PPR; printf(METADATA block #%u\n, block_number);
PPR; printf( type: %u (%s)\n, (unsigned)block-type, block-type
FLAC__METADATA_TYPE_UNDEFINED? FLAC__MetadataTypeString[block-type] :
UNKNOWN);
PPR; printf( is last: %s\n, block-is_last? true:false);
diff --git a/src/metaflac/operations_shorthand_vorbiscomment.c
b/src/metaflac/operations_shorthand_vorbiscomment.c
index 3d381a5..19f9602 100644
--- a/src/metaflac/operations_shorthand_vorbiscomment.c
+++ b/src/metaflac/operations_shorthand_vorbiscomment.c
@@ -96,7 +96,11 @@ FLAC__bool do_shorthand_operation__vorbis_comment(const char
*filename, FLAC__bo
ok = remove_vc_firstfield(filename, block,
operation-argument.vc_field_name.value, needs_write);
break;
case OP__SET_VC_FIELD:
+#ifdef _WIN32 /* do not convert anything or things will break */
+ ok = set_vc_field(filename, block,
operation-argument.vc_field, needs_write, true);
+#else
ok = set_vc_field(filename, block,
operation-argument.vc_field, needs_write, raw);
+#endif
break;
case OP__IMPORT_VC_FROM:
ok = import_vc_from(filename, block,
operation-argument.filename, needs_write, raw);
@@ -245,9 +249,7 @@ FLAC__bool set_vc_field(const char *filename,
FLAC__StreamMetadata *block, const
}
else {
FLAC__bool needs_free = false;
-#ifdef _WIN32 /* do not convert anything or things will break */
entry.entry = (FLAC__byte *)field-field;
-#else
if(raw) {
entry.entry = (FLAC__byte *)field-field;
}
@@ -259,7 +261,6 @@ FLAC__bool set_vc_field(const char *filename,
FLAC__StreamMetadata *block, const
flac_fprintf(stderr, %s: ERROR: converting comment
'%s' to UTF-8\n, filename, field-field);
return false;
}
-#endif
entry.length = strlen((const char *)entry.entry);
if(!FLAC__format_vorbiscomment_entry_is_legal(entry.entry,
entry.length)) {
if(needs_free)
diff --git a/src/metaflac/utils.c b/src/metaflac/utils.c
index 8b91011..be5a3c1 100644
--- a/src/metaflac/utils.c
+++ b/src/metaflac/utils.c
@@ -229,13 +229,18 @@ void write_vc_field(const char *filename, const
FLAC__StreamMetadata_VorbisComme
{
if(0 != entry-entry) {
if(filename)
- fprintf(f, %s:, filename);
+ flac_fprintf(f, %s:, filename);
if(!raw) {
/*
* WATCHOUT: comments that contain an embedded null will
* be truncated by utf_decode().
*/
+#ifdef _WIN32 /* if we are outputting to console, we need to use proper print
functions to show unicode characters */
+ if (f == stdout || f == stderr) {
+ flac_fprintf(f, %s, entry-entry);
+ } else {
+#endif
char *converted;
if(utf8_decode((const char *)entry-entry, converted)
= 0) {
@@ -245,6 +250,9 @@ void write_vc_field(const char *filename, const
FLAC__StreamMetadata_VorbisComme
else {
(void) local_fwrite(entry-entry, 1,
entry-length, f);
}
+#ifdef _WIN32
+ }
+#endif
}
else {
(void) local_fwrite(entry-entry, 1, entry-length, f);
diff --git a/src/share/utf8/utf8.c b/src/share/utf8/utf8.c
index beb815a..18495fe 100644
--- a/src/share/utf8/utf8.c
+++ b/src/share/utf8/utf8.c
@@ -203,7 +203,7 @@ int utf8_decode(const char *from, char **to)
return -1;
}
-chars = WideCharToMultiByte(GetConsoleCP(), WC_COMPOSITECHECK, unicode,
+chars = WideCharToMultiByte(CP_ACP,
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 text required new line.
Patches applied. Thanks!
Erik
Either I sent a wrong patch or the last fix didn't make it in. Here's a
patch to git version to fix old status print staying on the wrong line
with certain filename length.
diff --git a/src/flac/utils.c b/src/flac/utils.c
index 03dbdc8..85a16f0 100644
--- a/src/flac/utils.c
+++ b/src/flac/utils.c
@@ -229,7 +229,7 @@ void stats_print_name(int level, const char *name)
void stats_print_info(int level, const char *format, ...)
{
char tmp[80];
- int len, cleared_len;
+ int len, clear_len;
if (flac__utils_verbosity_ = level) {
va_list args;
@@ -240,10 +240,10 @@ void stats_print_info(int level, const char *format, ...)
tmp[sizeof(tmp)-1] = '\0';
len = sizeof(tmp)-1;
}
- cleared_len = stats_char_count;
stats_clear();
if (len = console_chars_left) {
- while (cleared_len 0 cleared_len--)
fprintf(stderr, );
+ clear_len = console_chars_left;
+ while (clear_len 0 clear_len--) fprintf(stderr,
);
fprintf(stderr, \n);
console_chars_left = console_width;
}
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
[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 fixes this.
diff --git a/include/share/win_utf8_io.h b/include/share/win_utf8_io.h
index b48e85e..b689db0 100644
--- a/include/share/win_utf8_io.h
+++ b/include/share/win_utf8_io.h
@@ -10,7 +10,7 @@ extern C {
#include stdio.h
#include sys/stat.h
#include stdarg.h
-
+#include windows.h
int get_utf8_argv(int *argc, char ***argv);
@@ -25,6 +25,7 @@ int chmod_utf8(const char *filename, int pmode);
int utime_utf8(const char *filename, struct utimbuf *times);
int unlink_utf8(const char *filename);
int rename_utf8(const char *oldname, const char *newname);
+HANDLE WINAPI CreateFile_utf8(const char *lpFileName, DWORD dwDesiredAccess,
DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD
dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile);
#ifdef __cplusplus
} /* extern C */
diff --git a/src/share/grabbag/file.c b/src/share/grabbag/file.c
index dd2880c..a3706f1 100644
--- a/src/share/grabbag/file.c
+++ b/src/share/grabbag/file.c
@@ -127,8 +127,8 @@ FLAC__bool grabbag__file_are_same(const char *f1, const
char *f2)
BY_HANDLE_FILE_INFORMATION info1, info2;
HANDLE h1, h2;
BOOL ok = 1;
- h1 = CreateFile(f1, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
- h2 = CreateFile(f2, GENERIC_READ, FILE_SHARE_READ, NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
+ h1 = CreateFile_utf8(f1, GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
+ h2 = CreateFile_utf8(f2, GENERIC_READ, FILE_SHARE_READ, NULL,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if(h1 == INVALID_HANDLE_VALUE || h2 == INVALID_HANDLE_VALUE)
ok = 0;
ok = GetFileInformationByHandle(h1, info1);
diff --git a/src/share/win_utf8_io/win_utf8_io.c
b/src/share/win_utf8_io/win_utf8_io.c
index d7d1dbd..d2288d9 100644
--- a/src/share/win_utf8_io/win_utf8_io.c
+++ b/src/share/win_utf8_io/win_utf8_io.c
@@ -262,3 +262,16 @@ int rename_utf8(const char *oldname, const char *newname)
return ret;
}
+
+HANDLE WINAPI CreateFile_utf8(const char *lpFileName, DWORD dwDesiredAccess,
DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes, DWORD
dwCreationDisposition, DWORD dwFlagsAndAttributes, HANDLE hTemplateFile)
+{
+ wchar_t *wname;
+ HANDLE handle = INVALID_HANDLE_VALUE;
+
+ if ((wname = wchar_from_utf8(lpFileName)) != NULL) {
+ handle = CreateFileW(wname, dwDesiredAccess, dwShareMode,
lpSecurityAttributes, dwCreationDisposition, dwFlagsAndAttributes,
hTemplateFile);
+ free(wname);
+ }
+
+ return handle;
+}
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
[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 it did so for all locales I tried (Finnish, German, English US).
diff --git a/src/metaflac/utils.c b/src/metaflac/utils.c
index 934cfcf..debc11e 100644
--- a/src/metaflac/utils.c
+++ b/src/metaflac/utils.c
@@ -77,17 +77,23 @@ void local_strcat(char **dest, const char *source)
safe_strncpy((*dest)+ndest, source, ndest + nsource + 1);
}
+static inline int local_isprint(int c)
+{
+ if (c 0x32) return 0;
+ return isprint(c);
+}
+
void hexdump(const char *filename, const FLAC__byte *buf, unsigned bytes,
const char *indent)
{
unsigned i, left = bytes;
const FLAC__byte *b = buf;
for(i = 0; i bytes; i += 16) {
- flac_printf(%s%s%s%08X:
+ flac_printf(%s%s, filename? filename:, filename? ::);
+ printf(%s%08X:
%02X %02X %02X %02X %02X %02X %02X %02X
%02X %02X %02X %02X %02X %02X %02X %02X
%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c%c\n,
- filename? filename:, filename? ::,
indent, i,
left 0? (unsigned char)b[ 0] : 0,
left 1? (unsigned char)b[ 1] : 0,
@@ -105,22 +111,22 @@ void hexdump(const char *filename, const FLAC__byte *buf,
unsigned bytes, const
left 13? (unsigned char)b[13] : 0,
left 14? (unsigned char)b[14] : 0,
left 15? (unsigned char)b[15] : 0,
- (left 0) ? (isprint(b[ 0]) ? b[ 0] : '.') : ' ',
- (left 1) ? (isprint(b[ 1]) ? b[ 1] : '.') : ' ',
- (left 2) ? (isprint(b[ 2]) ? b[ 2] : '.') : ' ',
- (left 3) ? (isprint(b[ 3]) ? b[ 3] : '.') : ' ',
- (left 4) ? (isprint(b[ 4]) ? b[ 4] : '.') : ' ',
- (left 5) ? (isprint(b[ 5]) ? b[ 5] : '.') : ' ',
- (left 6) ? (isprint(b[ 6]) ? b[ 6] : '.') : ' ',
- (left 7) ? (isprint(b[ 7]) ? b[ 7] : '.') : ' ',
- (left 8) ? (isprint(b[ 8]) ? b[ 8] : '.') : ' ',
- (left 9) ? (isprint(b[ 9]) ? b[ 9] : '.') : ' ',
- (left 10) ? (isprint(b[10]) ? b[10] : '.') : ' ',
- (left 11) ? (isprint(b[11]) ? b[11] : '.') : ' ',
- (left 12) ? (isprint(b[12]) ? b[12] : '.') : ' ',
- (left 13) ? (isprint(b[13]) ? b[13] : '.') : ' ',
- (left 14) ? (isprint(b[14]) ? b[14] : '.') : ' ',
- (left 15) ? (isprint(b[15]) ? b[15] : '.') : ' '
+ (left 0) ? (local_isprint(b[ 0]) ? b[ 0] : '.') : '
',
+ (left 1) ? (local_isprint(b[ 1]) ? b[ 1] : '.') : '
',
+ (left 2) ? (local_isprint(b[ 2]) ? b[ 2] : '.') : '
',
+ (left 3) ? (local_isprint(b[ 3]) ? b[ 3] : '.') : '
',
+ (left 4) ? (local_isprint(b[ 4]) ? b[ 4] : '.') : '
',
+ (left 5) ? (local_isprint(b[ 5]) ? b[ 5] : '.') : '
',
+ (left 6) ? (local_isprint(b[ 6]) ? b[ 6] : '.') : '
',
+ (left 7) ? (local_isprint(b[ 7]) ? b[ 7] : '.') : '
',
+ (left 8) ? (local_isprint(b[ 8]) ? b[ 8] : '.') : '
',
+ (left 9) ? (local_isprint(b[ 9]) ? b[ 9] : '.') : '
',
+ (left 10) ? (local_isprint(b[10]) ? b[10] : '.') : '
',
+ (left 11) ? (local_isprint(b[11]) ? b[11] : '.') : '
',
+ (left 12) ? (local_isprint(b[12]) ? b[12] : '.') : '
',
+ (left 13) ? (local_isprint(b[13]) ? b[13] : '.') : '
',
+ (left 14) ? (local_isprint(b[14]) ? b[14] : '.') : '
',
+ (left 15) ? (local_isprint(b[15]) ? b[15] : '.') : ' '
);
left -= 16;
b += 16;
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 character under Windows when application isn't using C-locale. At least it did so for all locales I tried (Finnish, German, English US). I just realized I slipped wrong number in the printability check. Instead of 0x32 there should of course be 32. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 console length it kept printing the same line over and over. The patch I included fixes encoding side nicely, but on decoding side there is still minor glitch left. On long lines the final status of the decoding will still be printed on its own line. The Unicode printing patch no longer relies on character counts returned by fwprintf function as that didn't match reality. And I switched to use WriteConsole command when output isn't redirected so that special characters can be printed. They were replaced by question marks with fwprintf. Fixing fwprintf output would have required setting console mode to UTF-16 and that would have required all print functions to be replaced by wide char variants. Use of regular ansi function would instantly crash the program in that mode. The long line patch is broken and requires much more work, please ignore it. The other patch is still good. Here's a patch to get working Unicode support for one forgotten print function in metaflac. diff --git a/src/metaflac/utils.c b/src/metaflac/utils.c index 934cfcf..af17d5b 100644 --- a/src/metaflac/utils.c +++ b/src/metaflac/utils.c @@ -136,7 +136,7 @@ void print_error_with_chain_status(FLAC__Metadata_Chain *chain, const char *form va_start(args, format); - (void) vfprintf(stderr, format, args); + (void) flac_vfprintf(stderr, format, args); va_end(args); ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 defined. That has to be a mistake. Someone with access to those systems needs to test this. If it doesn't get tested it won't make it into the release. Erik Here's one more try to solve the compilation problem when non-existing unistd.h is tried to include with MSVC. It now includes it like before the cleanup so it shouldn't do any harm to environments that have worked in the past. diff --git a/include/share/compat.h b/include/share/compat.h index 88caf1e..222de65 100644 --- a/include/share/compat.h +++ b/include/share/compat.h @@ -93,13 +93,9 @@ #define FLAC__STRNCASECMP strncasecmp #endif -#if defined _MSC_VER || defined __MINGW32__ +#if defined _MSC_VER || defined __MINGW32__ || defined __CYGWIN__ || defined __EMX__ #include io.h /* for _setmode(), chmod() */ #include fcntl.h /* for _O_BINARY */ -#endif -#if defined __CYGWIN__ || defined __EMX__ -#include io.h /* for setmode(), chmod() */ -#include fcntl.h /* for _O_BINARY */ #else #include unistd.h /* for chown(), unlink() */ #endif ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 MSYS compile (I use MSYS build from
http://xhmikosr.1f0.de/tools/). All tests passed.
I noticed a typo in a warning text while running them though, here's a
patch for that.
diff --git a/src/metaflac/options.c b/src/metaflac/options.c
index 6aded4a..e8e6151 100644
--- a/src/metaflac/options.c
+++ b/src/metaflac/options.c
@@ -1084,5 +1084,5 @@ FLAC__bool parse_application_data_format(const char *in,
FLAC__bool *out)
void undocumented_warning(const char *opt)
{
- flac_fprintf(stderr, WARNING: undocmented option --%s should be used
with caution,\n only for repairing a damaged STREAMINFO block\n, opt);
+ flac_fprintf(stderr, WARNING: undocumented option --%s should be used
with caution,\n only for repairing a damaged STREAMINFO block\n, opt);
}
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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
progress_display: flac testing progress display used old functions that
didn't get utf-8 decoding
msvc_flac_version: changes versions number from 1.3.0pre2 to 1.3.0pre3
compat_h_msvc_fix: fixes compiling on MSVC
Applied, thanks!
Erik
Surprisingly flac_mac had mistakenly gotten extra parameters for safe
string functions requiring further patching.
And here's patches for the changes in git for flactimer.
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 defined. That has to be a mistake.
diff --git a/src/monkeys_audio_utilities/flac_mac/main.c
b/src/monkeys_audio_utilities/flac_mac/main.c
index 8c8fa3d..8ffa5b6 100644
--- a/src/monkeys_audio_utilities/flac_mac/main.c
+++ b/src/monkeys_audio_utilities/flac_mac/main.c
@@ -133,7 +133,7 @@ int main(int argc, char *argv[])
/* for the full 'from' and 'to' paths for the renamer process */
p = strrchr(argv[from_arg],'\\');
safe_strncat(from, p? p+1 : argv[from_arg], sizeof(from));
- safe_strncpy(to, from, sizeof(to), sizeof(to));
+ safe_strncpy(to, from, sizeof(to));
cptr = strrchr(from,'.');
if(cptr == NULL)
diff --git a/src/utils/flactimer/main.cpp b/src/utils/flactimer/main.cpp
index 068d518..85e8a33 100644
--- a/src/utils/flactimer/main.cpp
+++ b/src/utils/flactimer/main.cpp
@@ -19,6 +19,8 @@
#include stdio.h
#include string.h
#include windows.h
+#include share/compat.h
+#include share/safe_str.h
#define int64_t __int64
#define uint64_t unsigned int64_t
@@ -106,8 +108,8 @@ int main(int argc, char *argv[])
args[0] = '\0';
for(i = 0; i argc; i++) {
if(i 0)
- safe_strncat(args, sizeof(args), );
- safe_strncat(args, sizeof(args), argv[i]);
+ safe_strncat(args, , sizeof(args));
+ safe_strncat(args, argv[i], sizeof(args));
}
//fprintf(stderr, @@@ cmd=[%s] args=[%s]\n, argv[0], args);
diff --git a/src/utils/flactimer/flactimer.vcproj
b/src/utils/flactimer/flactimer.vcproj
index 3011f15..4496fa2 100644
--- a/src/utils/flactimer/flactimer.vcproj
+++ b/src/utils/flactimer/flactimer.vcproj
@@ -39,7 +39,7 @@
Tool
Name=VCCLCompilerTool
Optimization=0
- AdditionalIncludeDirectories=.
+
AdditionalIncludeDirectories=.;..\..\..\include
PreprocessorDefinitions=WIN32;_DEBUG;_CONSOLE;DEBUG
MinimalRebuild=true
BasicRuntimeChecks=3
@@ -116,7 +116,7 @@
FavorSizeOrSpeed=1
OmitFramePointers=true
WholeProgramOptimization=true
- AdditionalIncludeDirectories=.
+
AdditionalIncludeDirectories=.;..\..\..\include
PreprocessorDefinitions=WIN32;NDEBUG;_CONSOLE
RuntimeLibrary=0
BufferSecurityCheck=false
@@ -195,7 +195,7 @@
FavorSizeOrSpeed=1
OmitFramePointers=true
WholeProgramOptimization=true
- AdditionalIncludeDirectories=.
+
AdditionalIncludeDirectories=.;..\..\..\include
PreprocessorDefinitions=WIN32;NDEBUG;_CONSOLE
RuntimeLibrary=0
BufferSecurityCheck=false
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 the conversion function again with appropriate source codepage (when using W32 conversion functions that would be CP_ACP). If that fails, fail the function call as usual. I initially had it that way. I just didn't feel comfortable leaving it as it could in theory access wrong files. Granted, it would require having some rather weird names for files but it's still a possibility. (Sorry LRN for initially sending the mail directly in your box. I need to learn to press the right buttons.) ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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/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. +1 Erik Alright, here's a patch utilizing this function. There's a lot of changes here. Project files have a new configuration called Release (UTF8), intended to be used when building the command line tools. This project has the required UTF-8 define in place so all libraries expect things in encoded format. Regular Debug and Release configurations do not use any new tricks so existing projects won't break when compiled with those settings. I'm at work and couldn't do extensive testing, but command line FLAC.exe seems to perform everything right with this. Metaflac probably requires some minor tweaks but I wanted to show some progress so that 1.3 doesn't slip out the door while I'm busy. Should the following #if defined _MSC_VER || defined __MINGW32__ be simplified to #ifdef WIN32 ? Alternatively _WIN32. Since it's win32 and not something compiler specific. Indeed. Not sure what I was thinking. As for the macros: +#define flac_vfprintf vfprintf_utf8 +#define flac_fopen fopen_utf8 +#define flac_stat _stat64_utf8 ... I leave this up for Erik to decide, though I would have preferred not using rename macros at all. I think this is the sanest way. Only few #ifdefs instead of wrapper functions filled with them that do essentially nothing on *nix. Not sure if these were intended: +#include sys/stat.h /* for flac_stat() */ +#include sys/utime.h /* for flac_utime() */ +#include io.h /* for flac_chmod() */ Nope. Bug from mass replace. As for calling __wgetmainargs, I have some concerns about the security implications: LoadLibrary(msvcrt.dll) - Which msvcrt? Theoretical security exploit. There is msvcrt.dll in the System32 dir in all supported Windows systems. That is what the function targets, but of course LoadLibrary searches from exe's dir first. I think security exploit concerns are warrantless, if you can place malicious replacement c-runtime dll in the exe's path you have already won. I think it is best to link it directly, please use the following prototype and call it directly: = #ifdef _DLL #define CALL_DLLIMPORT __declspec(dllimport) #else #define CALL_DLLIMPORT #endif int __cdecl CALL_DLLIMPORT __wgetmainargs(int*, wchar_t***, wchar_t***, int, int*); = This should simplify the error handling logic and help against LoadLibrary handle leaks, though the leak should not be an issue in practice since it is only called once. The symbol should also be present in MSVCR* DLLs. This alone does nothing. It requires linking with an object file that then deals with the function. If we link against msvcrt.lib the flac.exe binary will no longer be static and it won't work without external runtimes (which would also be loaded from the exe's dir if they exist there). Linking with msvcmrt.lib won't find the function and unicode version msvcurt.lib causes this error: Error1error LNK2005: ___iob_func already defined in msvcurt.lib(MSVCR110.dll)G:\test\LIBCMT.lib(_file.obj)test Error2error LNK1169: one or more multiply defined symbols foundG:\test\Release\test.exetest In stat_utf8, dealing with 32bit/64bit time_t? The following check should really compile time rather than runtime: sizeof(*buffer) == sizeof(st) Entire stat_utf8 function can be removed. The code was changed later to always use stat64 one. Though I'd assume compiler to optimize sizeof checks appropriately. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 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 http://msdn.microsoft.com/en-us/library/8bch7bkk%28v=vs.80%29.aspx. To support unicode with these methods would require somewhat more #ifdef code in main. We'd need to change project files to define Unicode character set and turn main into _wmain and char *argv to wchar_t *argv. Also these are MSVC's internal features, if I'm not mistaken. Other compilers on Windows would then require different solutions. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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 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. I can't find its version info. MSDN only documents it as far as VS2010 (normal C functions are documented as far as VS2003), and it's not present in any header file i have. I don't think it is, you probably required to declare it yourself. The symbol is in the MSVCRXX runtime dll, all the way from MSVCRT.dll to MSVC2012 MSVCR110. Suffice to say it is always there. Seems you are correct. I just did some testing and the unicode version appears usable from ansi program too. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
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\flac.exeflac
Error 9 is related to the location of _safe_malloc_mul_2op_. It's
easiest to fix by having the code in utf8.c.
But that function is defined in src/share/grabbag/alloc.c and should
be getting linked into flac.exe. It doesn't need to be redefined in
utf8.c. Specifically, I think alloc.c should be added as one of the
build files in
src/share/grabbag/grabbag_static.vcproj
src/share/grabbag/grabbag_dynamic.vcproj
Please try this and if that fixes it, please send a patch containing
only that change.
I thought Ben Allison would have made a patch. Here's a patch for this.
I suppose we were all blind at first for the cause.
diff -rupN a/src/share/grabbag/grabbag_static.vcproj
b/src/share/grabbag/grabbag_static.vcproj
--- a/src/share/grabbag/grabbag_static.vcproj Wed Jan 2 13:49:55 2013
+++ b/src/share/grabbag/grabbag_static.vcproj Tue Mar 12 09:46:01 2013
@@ -163,6 +163,10 @@
UniqueIdentifier={4FC737F1-C7A5-4376-A066-2A32D752A2FF}
File
+ RelativePath=.\alloc.c
+
+ /File
+ File
RelativePath=.\cuesheet.c
/File
___
flac-dev mailing list
flac-dev@xiph.org
http://lists.xiph.org/mailman/listinfo/flac-dev
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 difficult to review because of its size. Sorry, I'm new at this. I don't know how things should be handled. And I had to do some more inline changing to get my MSVC 2012 to compile the sources. I would still like to have this problem explained to me. With the sources as they are compiling produces these errors (this on MSVC 2012 SP1 Express): Error1error LNK2001: unresolved external symbol _FLAC__bitreader_bits_left_for_byte_alignment G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_decoder.obj) flac Error2error LNK2001: unresolved external symbol _FLAC__bitreader_is_consumed_byte_aligned G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_decoder.obj) flac Error3error LNK2001: unresolved external symbol _FLAC__bitreader_read_uint32_little_endian G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_decoder.obj) flac Error4error LNK2001: unresolved external symbol _FLAC__bitreader_get_input_bits_unconsumed G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_decoder.obj) flac Error5error LNK2001: unresolved external symbol _FLAC__bitwriter_write_raw_uint64 G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_encoder_framing.obj) flac Error6error LNK2001: unresolved external symbol _FLAC__bitwriter_write_raw_int32 G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_encoder_framing.obj) flac Error7error LNK2001: unresolved external symbol _FLAC__bitwriter_write_byte_block G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_encoder_framing.obj) flac Error8error LNK2001: unresolved external symbol _FLAC__bitwriter_write_raw_uint32_little_endian G:\Programming\flac-1.3.0pre2\src\flac\libFLAC_static.lib(stream_encoder_framing.obj) flac 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\flac.exeflac Error 9 is related to the location of _safe_malloc_mul_2op_. It's easiest to fix by having the code in utf8.c. There may still be some bug in FLAC's large input wav handling as the test FLAC I created by encoding over 22 hours of 24 bit data makes foobar2000 report one sample mismatch in reported and decoded length. Or it's a rounding bug in foobar2000. Is it not possible to test this without involving foobar2000? It is and I actually verified it yesterday. I used the command-line flac to decode the file into RAW format and calculated sample count by dividing it with bytes per sample and channel count. It matched the reported sample count exactly, so it's not a bug in FLAC. ___ flac-dev mailing list flac-dev@xiph.org http://lists.xiph.org/mailman/listinfo/flac-dev
