1) the encoding algorithm is standardized, correct? that is, obviously it is going to provide lossless encoding/decoding, and compress to (at least) the same filesize as one encoded with the original FLAC.exe? i know there were some projects going on trying to increase performance/compression on this codec.... which i don't like, standards are made for reasons
2) you say the current algorithm for encoding is i/o bound, i'm assuming this means the encoder can encode faster than the hard drive can read/supply the data, is this what you mean? unfortunately, this probably means that on faster systems, the speed improvement (vs. the original encoder) will have a tendency to decline the faster the system gets. fortunately, this also will improve with current and future tech like SSD drives...
Considering that EAC only passes one file at a time and has its own internal ability to make use of multiple processes, can someone please explain how you derive a benefit from this program with EAC?
Perhaps you could have made it a little more clear as to what your encoder does so that idiots like me wouldn't have to ask such stupid questions.
Quote from: GeorgeFP on 04 December, 2009, 06:27:12 AMTo use "fpMP3" or "fpFLAC2MP3" you have to download the source code and build the "fpMP3_DLL" project (Blend, SSE2, or SSE4 version). The built DLLs have to be registered with "regsvr32" (admin rights required for that).I would like to use fpFLAC2MP3. But I'm not able to build the project. I'm just not into this subject.Maybe somebody smart who owns all the needed software likes to build the project and upload it here in the forum? That would be very appreciated.
To use "fpMP3" or "fpFLAC2MP3" you have to download the source code and build the "fpMP3_DLL" project (Blend, SSE2, or SSE4 version). The built DLLs have to be registered with "regsvr32" (admin rights required for that).
I keep getting an error that a number of files 'failed to register'. Anyone else experiencing this? Files are installed into the Program Files directory, but any conversion fails in Foobar.
regsvr32 fpFLAC.dllregsvr32 fpFLAC_SSE2.dllregsvr32 fpFLAC_SSE4.dllregsvr32 fpMP3.dllregsvr32 fpMP3_SSE2.dllregsvr32 fpMP3_SSE4.dllregsvr32 fpStreamLib.dllregsvr32 fpWave.dllregsvr32 lFLAC.dllregsvr32 lVorbis.dll
I cannot wait for this to be ready for production so to speak!
Any chance @ GPU support?
Well, the truth is, I don't know if fpFLAC has a future. The feedback is very, very poor.
Josh, if you are interested, i'm ready to spend some time helping to incorporate CUDA code.
Quote from: NuSkooler on 23 December, 2009, 12:16:47 PMI cannot wait for this to be ready for production so to speak!Well, the truth is, I don't know if fpFLAC has a future. The feedback is very, very poor.
1. For me FLAC is dead, it's too weak, so you came too late. Multithreaded wavpack or mac would probably make more sense.
3. Installers are annoying. Regular 7zip package would be better. Can't you make it work w/out registering these dlls? Also, I got error during registration of smth with SSE4 in the name. XP 32bit, SP3, Core 2 Duo. Program worked at least long enough to show help, seeing lacking switches, I didn't even bother to compress something.
But, personally, I'm not very inclined to switch to a new, unproven piece of software even if it incorporates proven code and/or algorithms like FLAC, WavPack, LAME, ...Maybe a better approach to this would be, to somehow try, to integrate these new projects into the existing, proven, codebase supervised and/or publicly supported by the original developers trying to maintain the same stability and quality of the original software. This might even be a different branch at first but I really think the "umbrella effect" could have a positive effect on the acceptance of the new code/projects by the users which ultimately will result in more useage and feedback.
Believe me, if I had the chance to integrate my framework into the existing C code I would have done so. But multi-core programming is very different to serial programming and thus, I had to write fpFLAC from scratch.Of course, you can wait until the original developers will add multi-core support to their projects. I don't know of any activities going in this direction, neither for FLAC nor for LAME.
Quote3. Installers are annoying. Regular 7zip package would be better. Can't you make it work w/out registering these dlls? Also, I got error during registration of smth with SSE4 in the name. XP 32bit, SP3, Core 2 Duo. Program worked at least long enough to show help, seeing lacking switches, I didn't even bother to compress something.I agree. Especially for "utility" type stuff. My suggestion: Statically link everything needed into a fpFLAC.exe. I believe this will make it much more open to the masses.
I really try to not underestimate the amount of work and research that goes into these projects and I can surely understand that saying something like "integration will yield benefit x and y" might sound much easier than actually doing it!However, the problem will remain for projects like fpFLAC and others that they are seen more like a proof of concept and hence are more interesting for developers and testers which won't make a large userbase. This might actually not be a problem if the goal is to provide a proof of concept, but if the idea is to get more and more realworld usage/feedback I think somewhere along the line the proof of concept stage has to evolve into something more users will (want to) use. This is where the "umbrella effect" or "public developer support" might play a role as it gives visibility to these projects beyond this forum and also, kind of, assures the large group of endusers that it's OK to also use this for anything else than testing.