We use emboss seqret:

$EMBOSS_HOME/seqret fastq-illumina::phred64Data.fastq fastq::phred33Data.fastq

Galaxy's FASTQ groomer will do this job if you don't mind the web interface.

I haven't used this particular tool, but here is a tool built with Jim Kent's libraries to do the conversion 64to33 (or 33to64).

It comes with a makefile and all the includes necessary so it should be quite fast.

EDIT: there's also a very nice C-API in the Kent-tools: https://github.com/jstjohn/KentLib/blob/master/lib/fastq.c The function signature looks like:

inline void phred64ToPhred33( char * p64, int l)

So it should be easy to use.

You an use the HTSeq package in python: http://www-huber.embl.de/users/anders/HTSeq/doc/sequences.html#sequences. It will read fastq files with any of the common quality encodings, but always write using the Sanger (Phred) encoding.

A dirty and quick solution would be to make a FASTA file with Ns or any other rarely occurring homopolymer sequence of length equal to your read length. Align you FATSQ file against this reference with any quality aware aligner like BWA or Bowtie to get the BAM file (you can parallelize it for speed). Now by definition in BAM file quality scores are recored as Sanger scores. All the reads will be reported only once as unaligned reads. Now you can use Picard to get the Fastq back from the BAM file with Sanger scores!

Note: there is a difference in the way quality scores are recored in Ilummina Fastq files pre and post 1.3 version of Casava.

http://en.wikipedia.org/wiki/FASTQ_format

For anyone dealing with the problem of various fastq encoding schemes and looking to do some sanity checks on their method of conversion. Or, if you just want to look up the phred score for specific ascii code under one of the different schemes. I have found this blog entry extremely useful. It provides Sanger (And Illumina 1.3+ (And Solexa)) Phred Score (Q) ASCII Glyph Base Error Conversion Tables.