Audacity help needed

Archived from groups: rec.audio.pro (More info?)

Hi;
About 10 months ago I used Audacity to make a large recording on my PC.
I edited several tracks and exported them out as mp3s with no problem.
I had the intention of coming back later to finish the project.

I just sat back down with this project, and when I opened the data
folder, I found it contains thousands of files containing about 6
seconds at a time of each channel of the original recording recording.
This is nothing like what I recall.

Is there an automated or simple way to reassemble this data for editing
that I am overlooking? I tried to manually work on it, but it's way to
cumbersome.

Any help is appreciated.

Archived from groups: rec.audio.pro (More info?)

Mike Rivers wrote:
> In article <1106558215.180297.108700@c13g2000cwb.googlegroups.com> tcbten5@hotmail.com writes:
>
>
>>About 10 months ago I used Audacity to make a large recording on my PC.
>>I edited several tracks and exported them out as mp3s with no problem.
>>I had the intention of coming back later to finish the project.
>>
>>I just sat back down with this project, and when I opened the data
>>folder, I found it contains thousands of files containing about 6
>>seconds at a time of each channel of the original recording recording.
>>This is nothing like what I recall.
>
>
> Did you save the "project" after your editing work? That's what glues
> all of those little pieces together. I don't remember the extension of
> that files, but see what else is there that looks like it might be the
> title of the project.
>
> If you don't have that Audacity "project" file, I don't know how to
> put Humpty Dumpty back together again.
>

An Audacity project has the extension .aup. They usually look something
like a file called Project.aup and a directory called Project_data. I
discovered earlier today that Audacity can screw up the project file by
entering the project name incorrectly in the .aup file, so that you get
the tracks in the right places but no audio there. Luckily it's an XML
file so it was easy to fix.

--
Cheers,
Michael

Archived from groups: rec.audio.pro (More info?)

Mike Rivers wrote:
> I'm not sure I know what an XML file is, so it probably wouldn't be
> easy for me to fix. I use Audacity in a pretty simple way - straight
> recording and simple editing, saving my work as a WAV file (I guess
> that's "export" rather than "save" ) so I know what and where it is and
> what I can do with it.

An XML file is like an HTML file, except that it can be used for
anything. And I mean *anything*. You get to create your own tags,
so basically XML is a simple, clean (although verbose) way of
figuring out how to put virtually anything into a text file.

This could be an XML file:

<newsgroups>
<group name="rec.audio.pro">
<common-tangent>politics</common-tangent>
<common-tangent>religion</common-tangent>
<common-tangent>the bad pop music these days</common-tangent>
</group>
</newsgroups>

Or this could be an XML file describing things I need to do over
the next few days:

<day date="2005-01-25">
<task>
<name>take out trash</name>
<priority>urgent</priority>
</task>
<task>
<name>organize my rubber band collection</name>
<priority>low</priority>
</task>
</day>
<day date="2005-01-26">
<task>
<name>go to that stupid meeting</name>
</task>
<task>
<name>do a load of laundry</name>
</task>
</day>

Anyway, part of the point of XML is that basically anybody can look
at it and figure out what it means and what to do with it.
(Unfortunately, in practice sometimes XML files get to be hundreds
of thousands of lines long, so that doesn't always work, but
in *principle*...)

- Logan

Archived from groups: rec.audio.pro (More info?)

On Tue, 25 Jan 2005 14:51:39 +0000, Charles Krug wrote:

> On 25 Jan 2005 00:08:16 -0500, Mike Rivers <mrivers@d-and-d.com> wrote:
>>
>> In article <35l91lF4lhdfbU1@individual.net> no-alarms@no-surprises.co.uk writes:
>>
>>> An Audacity project has the extension .aup. They usually look something
>>> like a file called Project.aup and a directory called Project_data. I
>>> discovered earlier today that Audacity can screw up the project file by
>>> entering the project name incorrectly in the .aup file, so that you get
>>> the tracks in the right places but no audio there. Luckily it's an XML
>>> file so it was easy to fix.
>>
>> I'm not sure I know what an XML file is, so it probably wouldn't be
>> easy for me to fix. I use Audacity in a pretty simple way - straight
>> recording and simple editing, saving my work as a WAV file (I guess
>> that's "export" rather than "save" ) so I know what and where it is and
>> what I can do with it.
>>
>
> XML is plain text. Plain text can be fixed with vi (the One True
> Editor) or EMACS (a decent OS that lacks a good editor) rather than
> proprietary tools.
>
> The "trick" is knowing what the various tags mean. MS has moved towards
> using XML lately, but don't bother asking them about their tags--not
> something a recording engineering should be worrying about, IMO, but
> some guys like futzing with bits.
>
> My alternative to Audacity is some Turtle Beach package I bought because
> it came with a game port MIDI cable and was cheaper than the cable by
> itself.
>
> Audacity works better and has thus far been Good Enough for my needs,
> but I'm not doing commercial-scaled work. If you're running a business,
> you want it to Just Work. I'm not, so my next purchase will be GOOD
> monitors and hold off on making a software decision for another years
> tax refund.
>
> I've never had trouble with it, but . . .
>
> One of the issues with Linux in audio is that it's not "Hard Realtime"
> which is essential for lossless audio. Commercial software works around
> the limitations of Win32 or OS-X. Doing that is difficult and requires
> substantial mindshare--and money. There are hard-realtime versions of
> Linux, but they are commercial distros, not free versions.

There are hard realtime versions of Linux, but I don't think they are used
for audio.

You do low latency in normal Linux in much the same way as Windows and
OSX, by setting soft realtime with SCHED_FIFO. This says 'Always give this
process the cpu time it needs, but there is no absolute guarantee that it
will get it'.

Any program can request this in Windows at the moment, but as in Linux,
it's 'dangerous', ie any program with that priority can use all the
CPU time and lock the machine. While that's acceptable for Windows users,
it's not a long term solution, so Linux is moving to an OSX like method
with CPU limits on soft real time processes.

Still, the present method works well enough for low latency audio in
either OS.

Linux does perhaps have a small advantage when using JACK, as it acts as a
watchdog and can drop clients when they timeout.

>
> If it REALLY mattered, you'd use something like a small embedded
> processor running VxWorks, which is even more bucks, but designed from
> the ground up for hard realtime performance. N. B. that no audio
> package that I'm aware of goes to that trouble, Win32 and OX-x being
> Good Enough.

Real Hard Realtime brings it's own problems...For example it means
realtime threads locking memory, and not touching the disk drives as
they are non deterministic (the latency of a read/write cannot be
guaranteed). It works if you accept worst case scenarios for
everything, but that means low throughput.

>
> (Hard Realtime is best defined this way: "If an event happens that is
> not handled within x milliseconds, things will blow up -- sometimes
> literally." )