similar to: FLAC: specifying all files with extension .WAV

Hi, I have read this on the sourceforge site: Windows wildcards support for FLAC and Metaflac *Private: (?)<javascript:help_window('/help/tracker.php?helpname=private')> * No The Linux shell support wildcards but not the Windows shell. Would it be possible to add wildcard support for Windows? Example with Windows: metaflac --add-replay-gain *.flac Gives the following error:

the windows shell is broken w.r.t wildcards and probably always will be: http://www.hydrogenaudio.org/forums/index.php?showtopic=50667&st=75&p=466078&#entry466078 --- Harry Sack <tranzedude@gmail.com> wrote: > Hi, > > I want to use the "flac" encoder (in commandline mode) and I specify > this > command to encode all .WAV files in the current directory:

i had the problem is flac 1.1.2 so upgraded to 1.1.4 but now the problem is just different. the wav file is from audacity, so i guess it is culprit for setting that format type 1 bit, but shouldn't this still work? i found in 1.1.2 (before i found 1.1.3 had the odd size fix judging by relnotes) that i could add a dummy byte to the end and this seems to fix my issue, just not cleanly. here

Hi, since years I simply encoded my CDs using various tools to flac and simply listened to it and never had any problems. Today I wrote a little script though to add replaygain values to my music collection and I found out that a lot of my flac files are corrupt. The corruption almost always occurs in the last 10% like flac 1.2.1, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007 Josh

Hej, well I'm not sure because those file that are corrupt have been around for a quite long time. It could have been k3b but I'm really not sure. Right now I was ripping with Audex and tagging with Audex/Amarok/kid3. Those files seem to be fine though. My lates approaches have been with Picard/beets :-) I think it's not possible to share those files without getting in legal

Josh Coalson <xflac@yahoo.com> wrote: > --- Scott F <graue@oceanbase.org> wrote: > > > If I use flac to encode with the --replay-gain > > option, I get a warning about the --no-padding > > option... > > > > "NOTE: --replay-gain may leave a small PADDING block even with > > --no-padding" > > > > ...even though I'm

Hi, I'm using the FLAC command line tool to encode my WAV files in some directory to FLAC files. Now I noticed sometimes the output of the tool is mostly like this: flac -V --best "14 The Hose - Time Warp (Old Skull Mix).wav" flac 1.1.4, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are

A while back I posted about issues with flac files that were not able to be decoded. Here's what I do know: I've ripped most of my collection to my hard drive using KAudioCreator and I've specified that they be stored in flac format. All files play without trouble through Amarok. I found out there was a problem when I had selected files in a playlist and picked "burn"

So, let's provide some information then :-) ---------------------------------------------------------------------------------------------- soa2ii at thor /mnt/files/music/Slime/Alle gegen Alle $ flac -aF 02\ St?rtebecker.flac flac 1.2.1, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007 Josh Coalson flac comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome

If I use flac to encode with the --replay-gain option, I get a warning about the --no-padding option... "NOTE: --replay-gain may leave a small PADDING block even with --no-padding" ...even though I'm not using --no-padding. And the file does end up with a small padding block, so changing tags is slow. I'd fixed this bug in my own copy of flac 1.1.4, but forgot to submit the

A friend and I mirror our music collections on each other's servers; between the two of us we have several hundred gigs of flac files. My friend runs Linux, I run FreeBSD. Recently we started playing with flac-1.1.4 (we had been using flac-1.1.2 previously) and I noticed something strange. flac-1.1.4, run with identical options on identical files, produces different output on the linux

When decoding a FLAC file with bits per sample that is not a multiple of 8 and outputting in raw format, the decoder gets as far as the write callback before realising that it doesn't know how to write the data. It then fails with an unhelpful message (or trips an assert() in debug mode). The attached patch performs the check earlier, and gives a more helpful error message. Kind

Hello, I'm runing Debian Stable linux with flac version 1.2.1. Weekly, I run a cron job to test all my flac files for problems using the -ts options. I have several computers storing the same information over various raid arrays, and occasionally I do find the odd file that has had problems and can then change hard drives and re-synchronize. Anyways, I have recently encountered a couple of

Hello dudes, I had given up by the first one who answered, but I will go through this since two of you were interested about this... I actually don't care about the filesize, I just wanted to know what exactly causes this. (for the record, wavpack always produces the same filesize in win and lin). Here you go: djzn at orion:~$ flac --version flac 1.2.1 djzn at orion:~$ wine

Hi Matt, Any decent quad, quad-core Opteron system should be able to handle it with ease! :) -- Regards, Hilton Travis Phone: +61 (0)7 3344 3889 (Brisbane, Australia) Phone: +61 (0)419 792 394 Manager, Quark IT http://www.quarkit.com.au Quark AudioVisual http://www.quarkav.net http://www.threatcode.com/

Hi, Do you still know what tools you used to encode these FLAC-files? It seems similar errors have popped up elsewhere after using various tagging-utilities. It seems it is indeed a tagging issue, as the error indicates something in that direction and the errors always occur at the last few percent. I guess it isn't possible to share one of these files somewhere so I can have a look? If

Here you are: soa2ii at thor /mnt/files/music/Slime/Alle gegen Alle $ metaflac --list 02\ St?rtebecker.flac METADATA block #0 type: 0 (STREAMINFO) is last: false length: 34 minimum blocksize: 4608 samples maximum blocksize: 4608 samples minimum framesize: 14 bytes maximum framesize: 15637 bytes sample_rate: 44100 Hz channels: 2 bits-per-sample: 16 total samples: 5857656