Export drops last sample

[2eleven]

Hi Folks,

I've been putting off switching from cooledit pro/adobe audition to audacity mostly because of this apparent bug. I've seen it a few times before, and I found it again today. It makes me not trust Audacity.

I have a wav file ripped from a cd. If I open it in audacity 1.2.x or 1.3.x and immediately export it, the last sample will be truncated. I've only seen this happen on a few wav files, and no other audio application I have does this - only Audacity. The file is 22,752,072 samples long, which falls on a cdda frame boundary. After being exported, it is 22,752,071 samples long, which does not fall on a cdda frame boundary. Other than the missing last sample, the exported file is identical to the original, and it can be re-opened and re-exported without further sample drops. I am on a Mac, but I think I saw the same behavior on windows about a year or two ago.

I've searched the forums and can't find any posts related to this. Maybe someone has an idea of what is wrong here. I suspect it is a bug, but I may be wrong. I can make the file available to someone to download from my home webserver if you PM me.

Anyone have any ideas?

Thanks,

John

[steve]

I've no idea why, though I can confirm that it does drop the last sample on exporting a 22,752,072 sample file.
I'm also curious why it is a problem - my CD burning application can handle tracks of any length without issues.

[kozikowski]

<<<I've been putting off switching from cooledit pro/adobe audition to audacity mostly because of this apparent bug. I've seen it a few times before, and I found it again today. It makes me not trust Audacity.>>>

I continue to use all three many times a week. You're going to drop Cool Edit because....?

Koz

[2eleven]

I continue to use all three many times a week. You're going to drop Cool Edit because....?

Because I'm an advocate for cross-platform, open source software. I use linux, osx and windows regularly. I try to use applications which run on all three, and I prefer open source software for reasons of principle and cost.

John

[2eleven]

I've no idea why, though I can confirm that it does drop the last sample on exporting a 22,752,072 sample file.
I'm also curious why it is a problem - my CD burning application can handle tracks of any length without issues.

I suspect a bug needs to be reported. I tried emailing the feedback address listed on the wiki for reporting bugs, but the mail bounced.

John

[steve]

I have reported the issue to the developers, and that your e-mail bounced.

I'm still curious why this missing sample is a problem.

[2eleven]

I have reported the issue to the developers, and that your e-mail bounced.

Thanks.

I'm still curious why this missing sample is a problem.

Two problems. The first is that when a track does not end on a cdda frame boundary, your cd burning software will have to buffer the remaining samples - usually with silence - before burning. This causes a slight "glitch" between tracks when playing back cds where tracks are not separated by silence (live albums, for example). The second problem is simply that I don't trust an application fully when it drops samples without telling me!

John

[steve]

I've had a quick line back from one of the developers and apparently a message from you did get through on the "feedback" e-mail address. He's not had time to look at the issue yet, but (along the lines of my own thought on the issue) commented that a single dropped sample should not cause a problem with seamless tracks if you burn as one file with a cue sheet. I gave them a link to this topic, so if they find anything regarding this issue I expect they will post a comment.

[Gale Andrews]

I have now had a chance to make some tests on Windows with CVS HEAD. As I expected, there isn't any general problem with samples being dropped on export, rather a fringe issue where the exported audio is a specific length. I agree we want Audacity to always be sample accurate. But in your case this should not be an issue in practice, unless you are creating a new compilation CD from multiple CDs, and even then only if you import a WAV that has the exact length that hits this problem. Otherwise,

* rip the CD tracks as a single WAV file (for example with CDex) then burn the one file with a cue sheet, or

* Export with Snap To enabled (in the Selection Toolbar in 1.3.7), and the selection format set to "CDDA frames (75 fps)".

From the tests I have done with either Export or Export Selection to WAV 16 bit PCM:

* 22752072 samples (38694 CDDA frames) always exports as 22752071 samples (confirmed by checking the exported file in Foobar); note that changing the selection format to CDDA frames and exporting with Snap To enabled does not prevent the dropped sample)

* 28752024 samples (48898 CDDA frames) always exports correctly

* 28752072 samples (not on a CDDA boundary) always exports correctly

* 11376036 samples (22752072/2) always exports correctly

* 45504144 samples (22752072 * 2) always exports as 45504142 samples (2 dropped)

Then I did Export Multiple of two files from a track 22752072 samples long, with my split on a CD boundary at 13301736 samples. The files I got back were 9450336 and 13301736 samples = combined length of 22752072 samples, so correct.

So, the problem is with exporting audio with a length of 2275202 samples or multiples thereof, and possibly other numbers as well, if we find out the significance of this number. Have you found any other lengths that do this?

We'll track this bug now. I don't regard it as highly important, but I assume it should be easily fixable.


Gale

[2eleven]

Thanks for the analysis Gale. Where would be the right place to track this issue if I want to keep tabs on it?

Thanks again,

John