similar to: deafening silence

This will post-pend id3v1 tags. I thought they were found at the beginning of files. If not, then it looks fine to me. I may add some parentheses, though, like (tail -c 128 ${f} > tag) && (flac-0.8 -d $f ${f%flac}wav), etc. That decoding line should be "${f%.flac}", no "*", right? Same with the encoding command: flac-0.9 -V ${f%flac}wav $f Seem better? (-8

if your talking id3v1, something along the lines of (in bash): for f in *.flac ; do tail -c 128 $f > tag && flac-0.8 -d $f ${f%*.flac}.wav && flac-0.9 -V ${f%*.flac}.wav $f && cat tag >> $f ; done should work. of course, test it before you set it loose on your whole collection. if you're on windows, my condolences... no wait, just get cygwin :) Josh ---

I haven't seen too much feedback since the 0.9 release, which probably means one of three things: 1. it works perfectly and nobody has any complaints! 2. nobody is using 0.9. 3. the list is having problems. I mention #3 because at least one person has been blocked by sourceforge's new filter. Anyone...anyone? __________________________________________________ Do You Yahoo!? Get email

--- Asheesh Laroia <paulproteus@technologist.com> wrote: > However, I need its ID3 information. I need the client program > (i.e., > XMMS) to be able to look at a file and know its artist and title. > Those > are the only two required fields, as a matter of fact. > flac (the decoder) 'supports' ID3 and ID3v2 tags by ignoring them. The input plugins (including

I'm actually not using 0.9 yet. I have my CD collection archived in 0.8 format, and I want to keep my ID3 tags. If someone can whip up a script that lets me extract my ID3 tags to a file for each file, decompress into WAV, then recompress into 0.9 format, then re-integrate the ID3 data, that'd be good. Otherwise. I'll be stuck in 0.8 forever. Which I don't want.... -- Asheesh.

I have a CD collection of about 20 discs that I currently archive on my hard disk in MP3 format. No, I do not like lossy compression. No, I do not like closed standards. No, I do not like software patents (Fraunhofer). In fact, I do not even need compression at this point, as my hard disk capacity is greater than the sum total of the CDs' WAV-format sizes. However, I need its ID3

--- Asheesh Laroia <PaulProteus@technologist.com> wrote: > I'm running your debian packages on a K7 currently. They seem to be > working fine, including the xmms-flac package. I seem to be > experiencing > the same flac decoding problems > (state=6:FLAC__FILE_DECODER_STREAM_ERROR) > as Pritpaul Mahal, however. I'll see if I can reproduce these. It > could

I'm using dsync to synchronize emails on a laptop where wifi connectivity sometimes fails in the middle of a sync. I have a shell script that runs dsync, and here is one line of it including the output of dsync: + dsync -f -m realmail mirror /home/paulproteus/projects/ssh-attach/run ssh rose.makesad.us dsync dsync-local(paulproteus): Error: dbox

Yes, the tests are pretty exhaustive. Actually if you have the test_files/ directory checked out of CVS it will run even more tests. I reran all the tests again (asm optimizations on) on redhat 7.1 with gcc 2.96 and they all passed. They are also all passing on Windows with MSVC and OS X with gcc 2.95.2. Matt, there is a slight chance that your noise tests failed because your run produced the

I did an hg pull; hg update, and now my Dovecot working copy doesn't build: ../../src/lib-storage/index/dbox/libstorage_dbox.a(dbox-file.o): In function `dbox_file_metadata_get': /home/paulproteus/dnlds/dovecot/src/lib-storage/index/dbox/dbox-file.c:820: undefined reference to `dbox_file_maildir_metadata_get' collect2: ld returned 1 exit status make[3]: *** [imap] Error 1 make[3]:

Oct 21 10:04:05 alchemy dovecot: imap-login: Login: user=<paulproteus>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, TLS Oct 21 10:05:44 alchemy dovecot: IMAP(paulproteus): file message-decoder.c: line 289 (message_decode_body): assertion failed: (pos < input->size) Oct 21 10:05:44 alchemy dovecot: IMAP(paulproteus): Raw backtrace: imap [0x80c8e10] -> imap [0x80c8d1c] ->

I 'hg pull'ed and now my Dovecot segfaults when I select a particular folder. I've removed all files with 'index' in the name, so I don't think it's due to bad indexes. Oct 21 09:18:40 alchemy dovecot: Dovecot v1.1.beta3 starting up Oct 21 09:18:47 alchemy dovecot: imap-login: Login: user=<paulproteus>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, TLS

The RFC says <http://www.isi.edu/in-notes/rfc3501.txt> this: TEXT <string> Messages that contain the specified string in the header or body of the message. But with the current hg tip (see linked rawlogs), SEARCH TEXT provides results disjoint from SEARCH FROM. I guess that's a bug?

yeah, I would say hold off on a big conversion until 1.0. chances are low now that the format will change but it could happen. glad to hear from everyone that it's working. the only major hangup left seems to be seeking, which I am working on. 1.0 should be out in less than a month, at which time my 600+ CD collection goes in. "I'm not just the president... I'm also a

--- Asheesh Laroia <paulproteus@technologist.com> wrote: > Can't you write a script for ./configure that checks for this, rather > than > having the library do the check each time it's used? If not, perhaps > check /proc/cpuinfo or something. The DoIHaveSSE and DoIHave3DNow > checks > could fork() if the system provides fork(); if not, the checks would > return

Lo and behold, the new version of grip (http://www.nostatic.org/grip) has ID3V2 support. I want to be able to rip from grip, extract the data from the FLACs into WAVs, normalize the WAVs, then re-encode them into FLACs. How can I make sure the ID3V1 and ID3V2 tags stored by grip are saved in between the FLACs? What shell commands can I use to store the tags in a temp file? Thanks for

I've been with FLAC since 0.7, and I've loved the FLAC files I've ripped with grip, converted from FLAC 0.8 to 0.9, and played constantly on my desktop. And then I noticed the truncated ID3 tags in my FLAC files. I at first thought the problem lied in FLAC; I posted to this list, hoping for a solution. But then I realized my trusty GRIP was the flawed program. Now re-ripping my

I am currently in the process of converting my 8GB of FLAC 0.8 files into 0.9 files (1). As it converts, I wanted to know how everyone else's FLAC 0.9 compares to FLAC 0.8. One thing I noticed is that decompressing my FLAC files within XMMS gives it a 30% CPU usage constantly on my AMD K6-2 300. While this isn't the fastest machine, that's a lot of processing power being used. So,

I tagged some FLAC files with ID3V2 information (by the id3v2 program), but their metadata does not show up in XMMS. Anyone else have this problem? Anyone have a solution? (I tested the tags using the --list option of id3v2; they are there. XMMS and the FLAC plugin just don't seem to respect them.) -- Asheesh.

Hi Dovecot peeps, I'm enjoying running /usr/lib/dovecot/imap directly as a PREAUTH IMAP pipe. I find that it outputs log messages whose severity is INFO to stdout. I'm running it as follows: /usr/lib/dovecot/imap -c /tmp/dovecot.conf and I see the following messages output to stdout: * PREAUTH [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE SORT SORT=DISPLAY