Debian Bug report logs - #442433
normalize-audio: doesn't preserve the number of samples of normalized files

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Rogério Brito <rbrito@ime.usp.br>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: normalize-audio: doesn't preserve the number of samples of normalized files

Date: Mon, 3 Sep 2007 12:04:29 -0300

Package: normalize-audio
Version: 0.7.7-1
Severity: important

Hi.

I have a compressed CD file with flac (the whole CD in a flac file) that
is, unfortunately, due to the music industry, recorded with too much
dynamic range compression and way too loud.

This causes, in particular, clipping when the songs are compressed with,
say, an MP3 encoder (and then decoded).

As a way to remedy this, I chose to run normalize-audio (as I have been
doing for some time), but, today, I discovered the previously mentioned
CD file that after running normalize-audio, the post-processed file was
*shorter* than the original wav file.

In particular, if I:

* decompress it with flac;
* run normalize audio on it;
* try to compress it again with flac

flac complains that the file ended too short.

This must be a hard to track bug and I don't know if you will be able to
reproduce, but I can send you the whole CD image so that you can try. It
is, unfortunately, a 400MB+ long file and I don't know where I could put
it so that you could test it.

I also don't know if there are problems with 64-bit architectures (I
will try to use normalize audio on a 32-bit arch as soon as I have the
opportunity), but this is a very important bug, as it deals with file
corruption.

If you want any further information, please don't hesitate to ask. I
will try as hard as I can so that we can track it down and fix it.


Thanks, Rogério Brito.


-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.23-rc1 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=pt_BR (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash

Versions of packages normalize-audio depends on:
ii  libaudiofile0                0.2.6-7     Open-source version of SGI's audio
ii  libc6                        2.6.1-1     GNU C Library: Shared libraries
ii  libmad0                      0.15.1b-2.1 MPEG audio decoder library

Versions of packages normalize-audio recommends:
ii  vorbis-tools                  1.1.1-14   several Ogg Vorbis tools

-- no debconf information

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Message #8 received at 442433-submitter@bugs.debian.org (full text, mbox, reply):

From: Joachim Reichel <joachim.reichel@gmx.de>

To: 442433-submitter@bugs.debian.org

Subject: Re: Bug#442433: normalize-audio: doesn't preserve the number of samples of normalized files

Date: Sun, 16 Sep 2007 11:27:53 +0200

Hi,

do you use the normalize-mp3 script or do you perform
decompression/normalization/compression on your own?

In case you use the script: Can you please submit the output including
the error message? Does the script terminate after the error message, or
does it try to replace the original flac file with the generated flac file?

If you do not use the script: Do I understand you right, that the
normalize command exits without error message, with error code 0, and
the resulting wave file is shorter than the orginal?

Note that quite much disk space is needed in the process. Is it possible
that you run out of disk space and is this is somehow not detected?

How large is the uncompressed wav file? Is it larger than 2GB or 4GB?

Please let me know the exact commands including command line options
that you use.

Thanks,
  Joachim

Message #11 received at 442433-submitter@bugs.debian.org (full text, mbox, reply):

From: Joachim Reichel <joachim.reichel@gmx.de>

To: 442433-submitter@bugs.debian.org

Subject: Re: Bug#442433: normalize-audio: doesn't preserve the number of samples of normalized files

Date: Sun, 16 Sep 2007 13:36:12 +0200

I was able to reproduce the problem with a WAV file larger than 4 GB. On
an amd64 machine, normalize-audio processes the file without errors, but
the resulting file is exactly 4 GB smaller than the original file.

On i386, the program terminates with "Value too large for defined data
type" (and exit code 1). This happens also with file larger than 2 GB.

Message #20 received at 442433@bugs.debian.org (full text, mbox, reply):

From: Rogério Brito <rbrito@ime.usp.br>

To: Joachim Reichel <joachim.reichel@gmx.de>, 442433@bugs.debian.org

Cc: 442433-submitter@bugs.debian.org

Subject: Re: Bug#442433: normalize-audio: doesn't preserve the number of samples of normalized files

Date: Sun, 16 Sep 2007 21:20:36 -0300

Hi, Joachim.

On Sep 16 2007, Joachim Reichel wrote:
> do you use the normalize-mp3 script or do you perform
> decompression/normalization/compression on your own?

No, I'm not interested in the script. I use decompression, normalization
and compression, mostly because some of the files that I have are not
even in MP3 format. Some are in other formats (some lossless).

I have been using shntools's shnjoin to join the uncompressed wave files
and I was able to reproduce the problems even with an Intel machine
running MacOS X, which leads me to think that the problem may be
upstream.

I tried to read the source to see if I could easily spot the problem,
but it was taking too much time and I therefore have "paused" my reading
of the source code. :-(

> If you do not use the script: Do I understand you right, that the
> normalize command exits without error message, with error code 0, and
> the resulting wave file is shorter than the orginal?

I didn't see the return code of normalize, unfortunately, but it didn't
print any error message to stderr (which one would assume in case of
error, of course).

> Note that quite much disk space is needed in the process. Is it
> possible that you run out of disk space and is this is somehow not
> detected?

No, I have enough inodes for use (I have only 1% of them used) and
enough disk space for decompressing files (an external HD with 200GB
left for me to use).

> How large is the uncompressed wav file? Is it larger than 2GB or 4GB?

No, when the files are uncompressed, and joined together, they take
approximately 600MB, which is about the standard length of an audio CD.

> Please let me know the exact commands including command line options
> that you use.

For decompressing, say, mp3 files, I am using madplay. For joining the
resulting wave files, I am using shntools's shnjoin. Then, I normalize
the audio with a simple normalize call and split the files again with
shnsplit.

The exact commands for decompressing the files are listed here:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/sh

while read file; do
    file=${file##/Volumes/Backup/mp3/}
    directory=$(dirname "$file")
    filename=$(basename "$file" .mp3)

    mkdir -p "$directory" || true
    cd "$directory"
    madplay -a -3 -S -v -o "$filename.wav" "/Volumes/Backup/mp3/$file"
    cd ../..
done
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

And for recompressing are here:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
#!/bin/sh

while read line; do
    cd "$line"
    shnjoin [0-9]*.wav
    shncue  [0-9]*.wav > output.cue
    normalize-audio joined.wav
    cuebreakpoints output.cue | shnsplit joined.wav
    for i in split-track*.wav; do
        echo $line
        lame --noreplaygain -V 2 --vbr-new $i;
    done
    cd ../..
done
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Just after the call to normalize-audio I notice that I have problems
with the file and that it does not always contains the same number of
samples that it once contained. :-(

I have tested this doing this manually and compressing the file with
flac just before the normalize-audio step above and compressing it again
and flac complains that the file ended prematurely... :-( shnsplit also
gives me the same error message (with other words). :-(

Please, again, notice that this does not happen *every* time and, thus,
this is the reason why I have not posted this before. But I found some
albums that I have that *do* make normalize-audio exhibit the behavior
cited before. :-(


Thanks, Rogério Brito.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Message #28 received at 442433-quiet@bugs.debian.org (full text, mbox, reply):

From: Rogério Brito <rbrito@ime.usp.br>

To: Joachim Reichel <joachim.reichel@gmx.de>, 442433-quiet@bugs.debian.org

Cc: 442433-submitter@bugs.debian.org

Subject: Re: Bug#442433: normalize-audio: doesn't preserve the number of samples of normalized files

Date: Mon, 17 Sep 2007 07:24:53 -0300

Hi, Joachim.

On Sep 16, 2007, at 8:36 AM, Joachim Reichel wrote:

> I was able to reproduce the problem with a WAV file larger than 4  
> GB. On
> an amd64 machine, normalize-audio processes the file without  
> errors, but
> the resulting file is exactly 4 GB smaller than the original file.

No, I was able to reproduce the problem with much smaller WAV files  
(way less than 1GB, as I mentioned previously in an earlier message).  
BTW, if I recall correctly, WAV files greater than 1GB have to have  
extra headers in the middle of the file (ugh)... But the files that  
I'm dealing with (say, a CD extracted to wavpack and then used with  
normalize-audio) are much smaller than this.

> On i386, the program terminates with "Value too large for defined data
> type" (and exit code 1). This happens also with file larger than 2 GB.

I have not even tried to do this...

Do you have some audio CDs and some spare space? Perhaps you could  
try to extract the audio with "cdparanoia 1-" and then try to  
normalize the resulting file. I bet that you will find one such album  
in the first five or so albums that you try (this high error rate is  
what is giving me "headaches" and I wouldn't like to use audacity for  
the job, as I want to use tools as lightweight as possible for the job.


Thanks, Rogério.

-- 
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

Message #34 received at 442433-submitter@bugs.debian.org (full text, mbox, reply):

From: Joachim Reichel <joachim.reichel@gmx.de>

To: 442433-submitter@bugs.debian.org

Subject: Re: Bug#442433: normalize-audio: doesn't preserve the number of samples of normalized files

Date: Mon, 17 Sep 2007 17:46:18 +0200

Hi,

when you mentioned a compressed file of 400 MB size, I thought an MP3
file with a typical compression ratio of 1:10. Hence I wondered whether
the problem is related to 4 GB limits. If I understand the WAV
documentation [0] correctly, the size of a WAV file is limited to 2^32-1
bytes (+ header) since SubChunk2Size is a 32 bit integer.

[0] http://ccrma.stanford.edu/courses/422/projects/WaveFormat/

Hence, the huge WAV files that I produced with audacity (and audiofile)
were already broken and cannot be used to reproduce the problem. I will
file separate bugs against audacity and audiofile.

Can you call shninfo on the WAV file just before and after you call
normalize-audio? Is there a common characteristic in the problematic WAV
files that is not present in the unproblematic ones?

I will try to find some problematic files in my music collection.

Cheers,
  Joachim

Message #41 received at 442433-quiet@bugs.debian.org (full text, mbox, reply):

Hi, Joachim.

On Sep 17 2007, Joachim Reichel wrote:
> when you mentioned a compressed file of 400 MB size, I thought an MP3
> file with a typical compression ratio of 1:10.

Oh, sorry for not specifying that it was already uncompressed.

> Hence I wondered whether the problem is related to 4 GB limits. If I
> understand the WAV documentation [0] correctly, the size of a WAV file
> is limited to 2^32-1 bytes (+ header) since SubChunk2Size is a 32 bit
> integer.
> 
> [0] http://ccrma.stanford.edu/courses/422/projects/WaveFormat/

The RIFF/WAV specification is a mess, it seems to me. Some programs are
able to create and read files way larger than 2^32-1 bytes, but I don't
think that they can do that in a standard way.

But my problem is way simpler than that. I'm talking about files taken
about my compressed collection, for instance.

> Hence, the huge WAV files that I produced with audacity (and audiofile)
> were already broken and cannot be used to reproduce the problem. I will
> file separate bugs against audacity and audiofile.

Ok. Here is what flac has to say *after* I run normalize-audio on a file:

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
rbrito@chagas:/media/fw/lixo/songs$ flac joined.wav 

flac 1.1.4, Copyright (C) 2000,2001,2002,2003,2004,2005,2006,2007  Josh Coalson
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

joined.wav: 100% complete, ratio=0.601joined.wav: WARNING: unexpected EOF; expected 136473040 samples, got 136470528 samples
joined.wav: 100% complete, ratio=0.600
rbrito@chagas:/media/fw/lixo/songs$ 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Strange, huh?

> Can you call shninfo on the WAV file just before and after you call
> normalize-audio?

Sure, I can. The album above is the 2nd disc of Ayreon's "The Human
Equation". Here is the diff of the information that shninfo gives me
before and after I run normalize-audio on it. :-(

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
--- 1st.txt     2007-09-17 19:28:01.000000000 -0300
+++ 2nd.txt     2007-09-17 19:28:13.000000000 -0300
@@ -1,5 +1,5 @@
 -------------------------------------------------------------------------------
-File name:                    joined-before-normalize.wav
+File name:                    joined.wav
 Handled by:                   wav format module
 Length:                       51:34.47
 WAVE format:                  0x0001 (Microsoft PCM)
@@ -10,7 +10,7 @@
 Rate (calculated):            176400
 Block align:                  4
 Header size:                  44 bytes
-Data size:                    545892144 bytes
+Data size:                    545892160 bytes
 Chunk size:                   545892180 bytes
 Total size (chunk size + 8):  545892188 bytes
 Actual file size:             545892188
@@ -18,8 +18,8 @@
 Compression ratio:            1.0000
 CD-quality properties:
   CD quality:                 yes
-  Cut on sector boundary:     yes
-  Sector misalignment:        0 bytes
+  Cut on sector boundary:     no
+  Sector misalignment:        16 bytes
   Long enough to be burned:   yes
 WAVE properties:
   Non-canonical header:       no
@@ -27,7 +27,7 @@
 Possible problems:
   File contains ID3v2 tag:    no
   Data chunk block-aligned:   yes
-  Inconsistent header:        no
+  Inconsistent header:        yes
   File probably truncated:    no
   Junk appended to file:      no
   Odd data size has pad byte: n/a
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

> Is there a common characteristic in the problematic WAV files that is
> not present in the unproblematic ones?

Not that I happened to discover yet. :-(

> I will try to find some problematic files in my music collection.

Thanks. Could you please test the following:

	$ cdparanoia -B 1-
	$ shnjoin *.wav
	$ shncue track[0-9a-zA-Z]*.wav > output.cue
	$ normalize-audio joined.wav
	$ cuebreakpoints output.cue | shnsplit joined.wav

And see if the last song of the album is output by shnsplit correctly?

You should, obviously, have two identical copies of the album (except
for the volume of the audio, obviously), if everything is working
correctly.

If I use normalize-audio, I don't always get the last track output,
which is weird, very weird (and breaks the tools that I am using).

Please, I would be happy if you could test this.


Thanks, Rogério Brito.

-- 
Rogério Brito : rbrito@ime.usp.br : http://www.ime.usp.br/~rbrito
Homepage of the algorithms package : http://algorithms.berlios.de
Homepage on freshmeat:  http://freshmeat.net/projects/algorithms/

Message #47 received at 442433-submitter@bugs.debian.org (full text, mbox, reply):

From: "Rogério Brito" <rbrito@gmail.com>

To: 442433-submitter@bugs.debian.org, "Joachim Reichel" <joachim.reichel@gmx.de>

Subject: Re: Bug#442433: normalize-audio: doesn't preserve the number of samples of normalized files

Date: Tue, 18 Sep 2007 05:53:05 -0300

Hi, Joachim.

Please, the address rbrito@google  is wrongly configured. Please,
continue using the address rbrito@ime.usp.br so that we can find out
more about the problem.

Thanks, Rogério Brito.

Message #50 received at 442433-submitter@bugs.debian.org (full text, mbox, reply):

From: Joachim Reichel <joachim.reichel@gmx.de>

To: 442433-submitter@bugs.debian.org

Subject: Re: Bug#442433: normalize-audio: doesn't preserve the number of samples of normalized files

Date: Tue, 18 Sep 2007 19:28:40 +0200

Hi Rogério,

> Sure, I can. The album above is the 2nd disc of Ayreon's "The Human
> Equation". Here is the diff of the information that shninfo gives me
> before and after I run normalize-audio on it. :-(
> 
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> --- 1st.txt     2007-09-17 19:28:01.000000000 -0300
> +++ 2nd.txt     2007-09-17 19:28:13.000000000 -0300
> @@ -1,5 +1,5 @@
>  -------------------------------------------------------------------------------
> -File name:                    joined-before-normalize.wav
> +File name:                    joined.wav
>  Handled by:                   wav format module
>  Length:                       51:34.47
>  WAVE format:                  0x0001 (Microsoft PCM)
> @@ -10,7 +10,7 @@
>  Rate (calculated):            176400
>  Block align:                  4
>  Header size:                  44 bytes
> -Data size:                    545892144 bytes
> +Data size:                    545892160 bytes
>  Chunk size:                   545892180 bytes
>  Total size (chunk size + 8):  545892188 bytes
>  Actual file size:             545892188
> @@ -18,8 +18,8 @@
>  Compression ratio:            1.0000
>  CD-quality properties:
>    CD quality:                 yes
> -  Cut on sector boundary:     yes
> -  Sector misalignment:        0 bytes
> +  Cut on sector boundary:     no
> +  Sector misalignment:        16 bytes
>    Long enough to be burned:   yes
>  WAVE properties:
>    Non-canonical header:       no
> @@ -27,7 +27,7 @@
>  Possible problems:
>    File contains ID3v2 tag:    no
>    Data chunk block-aligned:   yes
> -  Inconsistent header:        no
> +  Inconsistent header:        yes
>    File probably truncated:    no
>    Junk appended to file:      no
>    Odd data size has pad byte: n/a
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

I observed similar results with some WAV files. But I'm not sure if
these differences are really a problem or if shninfo is not smart enough
(=> "Inconsistent header").

> Thanks. Could you please test the following:
> 
> 	$ cdparanoia -B 1-
> 	$ shnjoin *.wav
> 	$ shncue track[0-9a-zA-Z]*.wav > output.cue
> 	$ normalize-audio joined.wav
> 	$ cuebreakpoints output.cue | shnsplit joined.wav
> 
> And see if the last song of the album is output by shnsplit correctly?

This works fine for me.

I also ripped several CDs directly into one WAV file and called
normalize-audio. But I was not able to reproduce the problem: the
resulting file has the right number of samples.

> Please, the address rbrito@google  is wrongly configured. Please,
> continue using the address rbrito@ime.usp.br so that we can find out
> more about the problem.

Now I'm confused. If I'm not mistaken, I never used your GMail adress, I
just wrote to 442433-submitter@bugs.debian.org and the BTS has
rbrito@ime.usp.br recorded as the submitter address.

Regards,
  Joachim

Message #55 received at 442433-submitter@bugs.debian.org (full text, mbox, reply):

From: Joachim Reichel <joachim.reichel@gmx.de>

To: control@bugs.debian.org, 442433-submitter@bugs.debian.org

Subject: audiofile is buggy

Date: Mon, 24 Sep 2007 22:56:53 +0200

block 442433 by 443888
tag 422433 +confirmed
thanks

I downloaded your file and was able to reproduce the problem. I played
around with audiofile and it seems that the problem is caused by
audiofile itself. See #443888 for my bug report.

Regards,
  Joachim

Message #60 received at 442433-submitter@bugs.debian.org (full text, mbox, reply):

From: Rogério Brito <rbrito@ime.usp.br>

To: Joachim Reichel <joachim.reichel@gmx.de>

Cc: 442433-submitter@bugs.debian.org

Subject: Re: audiofile is buggy

Date: Tue, 25 Sep 2007 17:34:52 -0300

Hi, Joachim.

On Sep 24, 2007, at 5:56 PM, Joachim Reichel wrote:
> I downloaded your file and was able to reproduce the problem.

Thank you very much for being able to take the time to look at the  
problem with the package.

> I played around with audiofile and it seems that the problem is  
> caused by audiofile itself.

Excellent work isolating the problem. I was looking only at the  
source code of normalize-audio and it seemed to be fine. It didn't  
happen to me to check the dependencies of the package.

> See #443888 for my bug report.


Thanks, Rogério Brito.

-- 
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

Message #63 received at 442433-submitter@bugs.debian.org (full text, mbox, reply):

From: Rogério Brito <rbrito@ime.usp.br>

To: Joachim Reichel <joachim.reichel@gmx.de>

Cc: 442433-submitter@bugs.debian.org

Subject: Re: audiofile is buggy

Date: Tue, 25 Sep 2007 19:25:14 -0300

Dear Joachim,

On Sep 24, 2007, at 5:56 PM, Joachim Reichel wrote:
> I downloaded your file and was able to reproduce the problem. I played
> around with audiofile and it seems that the problem is caused by
> audiofile itself. See #443888 for my bug report.

Looking at the amount of bugs that the maintainer of audiofile has,  
it seems that the best situation, for the moment, would be to use the  
minimal audiofile-like clone that exists in normalize-audio itself.

I'm under MacOS X right now with a "hand-compiled" copy with "-- 
without-audiofile" passed to the configure script and it seems to be  
doing the job that I wanted in an automated and nice way, without  
other problems reported by other tools (like shntools or flac or  
anything else).


Regards, Rogério Brito.

-- 
Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8
http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito
Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org

Message #66 received at 442433-submitter@bugs.debian.org (full text, mbox, reply):

From: Joachim Reichel <joachim.reichel@gmx.de>

To: 442433-submitter@bugs.debian.org

Subject: Re: Bug#442433: audiofile is buggy

Date: Sun, 30 Sep 2007 18:19:47 +0200

> Looking at the amount of bugs that the maintainer of audiofile has, it
> seems that the best situation, for the moment, would be to use the
> minimal audiofile-like clone that exists in normalize-audio itself.

There is one serious bug and two wishlist  bugs...

> I'm under MacOS X right now with a "hand-compiled" copy with
> "--without-audiofile" passed to the configure script and it seems to be
> doing the job that I wanted in an automated and nice way, without other
> problems reported by other tools (like shntools or flac or anything else).

I confirm that the problem does not occur with the internal audiofile
implementation. But I'm hesitating to enable the internal implementation
since I do not know what features of audiofile are missing and how it
influences the operation of normalize-audio. This implementation might
have other bugs nor present in current audiofile.

I've informed audiofile upstream about #442433. Let's see if there is
some response.

Joachim

Message #71 received at 442433-done@bugs.debian.org (full text, mbox, reply):

From: Joachim Reichel <joachim.reichel@gmx.de>

To: 442433-done@bugs.debian.org

Subject: close bug

Date: Thu, 17 Dec 2009 20:52:20 +0100

Version: 0.7.7-1

Hi Rogerio,

bug #443888 in audiofile has been fixed recently. I no longer have the
audio file that you once provided for this bug and cannot verify that it
was only caused by the bug in audiofile. I have verified that the test
cases I produced some time ago (see #443888) work now. Therefore, I
believe that the bug you reported against normalize-audio was just
another manifestation of the bug in audiofile, and that there is no bug
in normalize-audio itself. If you still find problems, please file
another bug.

Thanks,
  Joachim

Message #76 received at 442433@bugs.debian.org (full text, mbox, reply):

From: Rogério Brito <rbrito@ime.usp.br>

To: 442433@bugs.debian.org

Cc: Joachim Reichel <joachim.reichel@gmx.de>

Subject: Re: Bug#442433 closed by Joachim Reichel <joachim.reichel@gmx.de> (close bug)

Date: Mon, 21 Dec 2009 20:44:32 -0200

Hi, Joachim.

On Dec 17 2009, Debian Bug Tracking System wrote:
> bug #443888 in audiofile has been fixed recently. I no longer have the
> audio file that you once provided for this bug and cannot verify that it
> was only caused by the bug in audiofile.

I don't expect the problem to be related to the content of the file, but
I will test that a bit latter.

I would like to just send a "thank you" note for taking care of this.


Regards,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 1024D/7C2CAEB8
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br

Send a report that this bug log contains spam.