Maybe making chcp an option (or an option to disable it) with a note in the readme that this feature doesn't work on XP?

I'll use some code that removes chcp from the batch file if running on XP. Really, this chcp-stuff is giving me lots of headache.

QUOTE (agentk7 @ Mar 15 2013, 21:20)

Wow, I was wondering if anyone would ever take up the mantle to improve/revamp Flac Frontend. I wanted to pass along my initial observations:

- When configuring the frontend I checked the box for "Keep foreign metadata". My first test was to decode some flac files and was immediately greeted with the command prompt error "ERROR reading foreign metadata: no foreign metadata found (017)". Perhaps this is a flac.exe issue and is fixed with the new version?

That's not a bug, it's a feature. Keep foreign metadata is an 'advanced' feature and should only be used if you know what you're doing, so enabling it for decoding while there's no foreign metadata indeed returns an error, that's by design.

QUOTE

One favorite feature of the old Flac Frontend was the fact that it preserved the file date of the input files. This version does not preserve the original file date

Weird, flac does this on linux by default as well. I'll take a look why this doesn't work on windows.

QUOTE

- Will the new Flac Frontend eventually have a config or ini file to save the settings?

Just curious, why does it need to write a batch file, instead of just running the executables with unicode command line?

The easiest way to feed back the output of the FLAC command is with the console. I tried to feed it back over the listbox but that didn't work very well. The problem is the status line that overwrites itself. Of course I could use a single command, but if a lot of files are given (>50) it has to be split into several commands because Windows has a certain maximum command length. If I would execute this without a batch file, several console windows would pop up to confuse the user.

I could try another way to display the output via the GUI though, with a textbox instead of a listbox. Maybe that would work.

It took a while (some bumps on the way) but it's fixed. Now FLAC frontend uses it's own console to process files instead of using a batch-file. Furthermore, I've created an installer that checks whether .NET Framework 2.0 is present and the program itself checks whether flac.exe and metaflac.exe are in it's path. This release uses the FLAC 1.3.0pre2 patched by Case for Unicode support, so it's not recommended to encode/decode anything critical with this.

Thanks! Works fine here. One thing i noticed is the replaygain values are the same for higher samplingrate material as the corresponding downsampled 44.1kHz version of it, nice. The value seems to be the same as the good old metaflac has calculated. I know this is not related to the frontend itself but maybe someone wonders.

Not a big deal but text not clearing completely on file names with special characters.

I know, but that's a work in progress. As the patch has not been merged yet (and I guess this is a part that the patch "forgot", while it is already a very large patch), I'll wait with reporting it until it is merged. Otherwise, it makes merging only more difficult I guess.

Codepage doesn't matter, it's doing the printing in unicode. The error was not 32 but 0x32, hex. It translates to "not supported". If you look at the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage you'll see that there are no UTF codepages there.

This is curious. I had made a silly mistake in my test program where I assumed error when SetConsoleOutputCP returned non-zero. It returns success code here too yet GetLastError returns "not supported" right afterwards. Also printing with WriteConsole gives UTF-8 garbage codes instead of translating them to anything intelligible. If this is supposed to work it certainly requires extra magic to take place.

Changes in beta 4:- Uses new compiles of flac 1.3.0pre3 + a few git fixes by Case. Known bugs: not correctly displaying non-latin chars in filenames- Installer shrunk from 1MB to 635kb- .NET 4.0 and 4.5 are supported. The installer simply packs two executables, one for .NET 2.0, 3.0 and 3.5 and one for .NET 4.0 and 4.5, and chooses which one should be installed. The .NET 4.0 version is preferred by the installer- Fixes a few minor bugs

Changes in beta 5- Uses new compiles for flac 1.3.0pre3 + UTF-8 and line break patches by Case. Now non-latin characters should be supported fully, at least as much as your version of Windows has the right console fonts.- Upgrading (from beta 3 or higher) was already possible, now downgrading (only to beta 4 now) is supported- Fixes line breaks in COPYING.GPL.txt and README.txt fixed, should now be readable with Notepad.- Now uses more explicit paths to make sure this won't happen- Uses smaller console because wide consoles are no longer necessary because of Case's line break patch- Added w64, raw and aiff to accepted input formats- Several small fixes (see git)

Why not? Ctrl+C or closing the window are usually ways to close an application, aren't they?

The problem is that encoding window is not a showing a child process, it's the main thread now. That is necessary to circumvent the UTF-8 problems with batchfiles. AFAIK it's either using a batch-file (and having lot's of problem with getting that to work) or this behaviour.

The scenario where I noticed the problem was that I had multiple files in the queue and I was working on a huge file that needed a long time to finish. I wanted to skip it and encode the rest but the program closed entirely. I think any alternate behavior would be better, like spawn new flac.exe process and continue encoding the next file or just remain open with the queue and let user reclick appropriate buttons.

I think this will get a little tricky. Now the output it sent to the console of the FLAC Frontend process itself. As the console is tied to the GUI, closing the console will close the GUI, they are just two different ways of input/output for the same process.

To get around this, I'll have to spawn separate processes. The problem is the communication between the processes: when calling a new process, there's a limit to the number of characters you can pass (little over 32000) which is just not enough if I were to test my whole library with FLAC frontend, which I think is not an unlikely case. I really don't like those artificial limits in programs. Communicating things to a new process with files is even more ugly (and might introduce problems like I had with using a batchfile or pose problems if the users tries to start a second thread) and I don't know of another way to pass information to another process.