Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Encoding to FLAC from CDex (Read 11134 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Encoding to FLAC from CDex

I decided to write this little primer because I became interested in FLAC, and wanted to encode files directly from CDex. I searched for similar posts, but only found info regarding FLAC and EAC. The command line for both is very similar, but some of the placeholders change a bit. Here are the steps:

1. Go to Options | Settings | Generic and set the ID3 Tag Version to None. This will prevent files named "name.flac.flac" from being created alongside the expected .flac file.

2. In Options | Settings | Encoder select External Encoder. Select "flac.exe" in the Encoder Path box. Check all three checkboxes at the bottom (Hide..., On-the-fly..., WAV header...).

3. Use this Parameter String:
Code: [Select]
-6 -o %2 -T "artist=%a" -T "title=%t" -T "album=%b" -T "date=%y" -T "tracknumber=%tn" -T "genre=%g" -


4. That's It!

Option -6 is being used because it gives me the best speed for the size. Here are the results of an informal test (Clapton - Layla):

Code: [Select]
1 - 1:10 - 48,921,005 bytes
6 - 1:15 - 46,856,722 bytes
8 - 4:17 - 46,801,659 bytes


So from 6 to 8, it takes 4 times as much, to save 50kBytes. No, thanks. And I guess the speed is limited by my reader (Yamaha SCSI CD-R).

I wish --replay-gain would work for files coming in from STDIN if they are written to a file. I mean, if -o is specified, then enable replay-gain. If you really want it, you can uncheck the "On-the-fly" option, and replace the "-" at the end of the string with a %1. That will calculate track gain. I don't see a way to calculate album gain, since CDex will be encoding one file at a time.

Well, there you go! Hope it helps someone!

Encoding to FLAC from CDex

Reply #1 –
You can try this 1.50 patch as an experiment use. This patch enables CDex 1.50 FLAC encoding.
Copy libFLAC.dll and libOggFLAC.dll to the CDex folder.

Encoding to FLAC from CDex

Reply #2 –
Well, the patch works! Copy the patch.exe to the CDex folder, and run it. Then copy libFLAC and libOggFLAC into the CDex directory.

It is fast. I was compressing at level 8 as fast as my CD-R could pump the bits out. But one problem... Winamp crashes when you try to go into the file info dialog. The files do play, however.

I imagine the problem is in the Winamp plugin. After all, it is using the DLLs included in the distribution. I tried the plugin that comes with FLAC 1.1.0 and X-Fixer's plugin. Are they the same now? Anyway, both crashed.

But there is hope! Maybe the bugs will get worked out and the patch will be included in the next version of CDex!

Encoding to FLAC from CDex

Reply #3 –
I use cdparanioa under Linux but always used EAC in windows and never set up Cdex. This inspired me, and using -q5 with the P4 optimised FLAC, it took 1m46s to rip Nirvana's Bleach, i chose that as it is in very bad condition.

That equates to a 24.17 greater than real time speed from starting the rip to having the compressed files on my hard disk, all i can say is WOW, that was wih full paranoia on!!!


All i have to do now is listen to it and see if the rip is pop free, hence why i used a bad CD.

If you are interested in my PC spec, its a P4 2.53@2.85 and a JLMS 166S DVD drive (Lite-on)

Just thought i'd let ya know my speed, don't recon i'll try that patch yet, what advantages does it offer??

Cheers,

Kristian

Encoding to FLAC from CDex

Reply #4 –
could you give a detailed report on that crash (winamp, OS etc.)?

also, could you cut the file to, say 50 Kb, and if it still crashes winamp upload it somewhere?

Encoding to FLAC from CDex

Reply #5 –
Ok... specs:

Celeron 400MHz, 320MB ram
Win2k SP2, Winamp 2.91
X-Fixer's Plugin (same size as the 1.1.0 plugin... havent compared bits tho)

I created the flac from one of the window's .wavs... forgot which one... I also saved the DrWatson log... dosnt seem to have much info, since whatever crashed does not have debug symbols. It is crashing because of a Div by 0 tho. I can repeat the crash every single time.

http://expert.cc.purdue.edu/~ariel/crash.flac
http://expert.cc.purdue.edu/~ariel/crash.log

PS. Hit "Save As..." for the flac.

Encoding to FLAC from CDex

Reply #6 –
in fact, this looks like FLAC encoder bug. the 'total_samples' field in the file is set to 0. (Josh, how come?)

Encoding to FLAC from CDex

Reply #7 –
X: you think this could be a bug in the patch (not calling the encoding functions with the proper parameters) or a bug in the flac DLLs? It is an un-official patch after all...

Are there any other programs that use the flac dlls? If those work right, then the problem is in the way the dlls are called. I haven't really done any research, but most programs that work with flac just call the executable.

Encoding to FLAC from CDex

Reply #8 –
I do not really know, but if/since flac.exe works, I'd suppose that FLAC APIs are used in a wrong way (not calling some clean-up function that updates the header).

for now, get the this version, that does not crash:
http://x-fixer.narod.ru/download/in_flac.zip

btw, have you checked that plug-in in 1.1.0 distribution is my? I'm somewhat interested to know.

Encoding to FLAC from CDex

Reply #9 –
Quote
in fact, this looks like FLAC encoder bug. the 'total_samples' field in the file is set to 0. (Josh, how come?)

If total_samples is 0, it means 'unknown'.  That means whoever called the encoder didn't tell it the total number of samples at encoder initialization time, and the encoder was unable to go back and rewrite the computed total itself after encoding (maybe because the client used the StreamEncoder, not the SeekableStreamEncoder or FileEncoder, or maybe because the client seek callback returned an error).

Josh

Encoding to FLAC from CDex

Reply #10 –
yep, it does not have a seektable as well. seems that they use StreamEncoder, not SeekableStreamEncoder. I hope they'll change it, otherwise seeking speed will suck.

anyway, now it should not crash on such files. (XMMS plug-in still should, IIRC)

Encoding to FLAC from CDex

Reply #11 –
Quote
yep, it does not have a seektable as well. seems that they use StreamEncoder, not SeekableStreamEncoder. anyway, now it should not crash on such files. (XMMS plug-in still should, IIRC)

ooh, where's the bug?

Encoding to FLAC from CDex

Reply #12 –
Quote
yep, it does not have a seektable as well. seems that they use StreamEncoder, not SeekableStreamEncoder. anyway, now it should not crash on such files. (XMMS plug-in still should, IIRC)

ooh, where's the bug?

Encoding to FLAC from CDex

Reply #13 –
false alarm. seems that I have forgot to insert this check when copying code from XMMS plug-in.

(XMMS plug-in will still crash if sample_rate, channels or bits_per_sample is set to 0, but such files are really corrupted)

Encoding to FLAC from CDex

Reply #14 –
X: The FLAC distro does not have your plugin. DOH! Got some files crossed around...

Anyway, I guess it is definetly NOT a flac bug. Just the way it is being called by CDex. Could someone write some code to do this properly, then submit it to the CDex dev? That way we don't have to fudge around with command line encoders or patch hacks?

Josh: Is there a way to do album replay gain when calling the DLL? That would be great if it could be integrated into CDex as well. Maybe with a call like "StartAlbum" then start encoding the files and at the end do a "EndAlbum"... but then you would have to go back to all the previous songs in the album and rewrite their tags... hmm. Anyway, great work with FLAC... it is my lossless encoder of choice!

Encoding to FLAC from CDex

Reply #15 –
btw, Josh, have you fixed that bug with seeking past the end of file?

it would be more easy to do this if you'll stop supporting seeking on files with total_samples set to 0 (seeking with streaming is not so useful imho). as a good side-effect, this will make a clear sign to users of libFLAC when they do something like this.

Encoding to FLAC from CDex

Reply #16 –
Quote
Josh: Is there a way to do album replay gain when calling the DLL? That would be great if it could be integrated into CDex as well. Maybe with a call like "StartAlbum" then start encoding the files and at the end do a "EndAlbum"... but then you would have to go back to all the previous songs in the album and rewrite their tags... hmm. Anyway, great work with FLAC... it is my lossless encoder of choice!

ReplayGain is not really part of a lossless codec, which is why it's not in libFLAC.  But the ReplayGain analysis and synthesis code is in separate convenience libraries in the FLAC distro, and those could be used.

Josh

Encoding to FLAC from CDex

Reply #17 –
Quote
btw, Josh, have you fixed that bug with seeking past the end of file?

it would be more easy to do this if you'll stop supporting seeking on files with total_samples set to 0 (seeking with streaming is not so useful imho). as a good side-effect, this will make a clear sign to users of libFLAC when they do something like this.

Yes, that bug is fixed in CVS.

Note that it is still possible to seek around in FLAC streams even if total_samples is 0, it will just be slower since that is one less piece of information the algorithm has to estimate the landing point.

Josh

Encoding to FLAC from CDex

Reply #18 –
Quote
btw, Josh, have you fixed that bug with seeking past the end of file?

it would be more easy to do this if you'll stop supporting seeking on files with total_samples set to 0 (seeking with streaming is not so useful imho). as a good side-effect, this will make a clear sign to users of libFLAC when they do something like this.

Yes, that bug is fixed in CVS.

Note that it is still possible to seek around in FLAC streams even if total_samples is 0, it will just be slower since that is one less piece of information the algorithm has to estimate the landing point.

Josh