Re: [Audacity-devel] Aup3 and blockfiles

[Leland <ll...@ho...>]

The sample data is just raw samples, no headers, but the samples can be in different formats.  You need to look at “sampleformat” in sampeblocks to get the format which are all little endian:

 

   int16Sample = 0x00020001,

   int24Sample = 0x00040001,

   floatSample = 0x0004000F,

 

The XML doc that you referred to is actually still being used, but it is stored in a “binary” format.  The easiest way to get an idea of the sequence the individual blocks are assigned to a specific channel would be to use “Help -> Generate Support Data” and look at the “project.txt” file.  The “decoder” for this XML doc can be found in “ProjectSerializer::Decode()”.

 

From: freddyjohn via audacity-devel <aud...@li...> 
Sent: Tuesday, March 23, 2021 7:56 PM
To: aud...@li...
Cc: freddyjohn <fre...@pr...>
Subject: Re: [Audacity-devel] Aup3 and blockfiles

 

 

I do not know what you mean by tracks and I am not talking about project files.

Specifically I am talking about these

 

SELECT samples FROM sampleblocks WHERE blockid=n

 

And 

 

If you look at blockfiles generated in >3 they are same structure just now in SQLite3 database inside .aup3 file instead of referenced via xml b-tree in .aup file

 

Is there anything special about these blockfiles? Are they more than just raw byte chunks of sampled audio? 

Those are the questions.

 

Sent from ProtonMail Mobile

 

 

On Tue, Mar 23, 2021 at 8:11 PM, Petr Pařízek via audacity-devel <aud...@li... <mailto:aud...@li...> > wrote:

Freddyjohn writes:

<<<<< 

Hello, I am writing an application similar to audacity for android. I am currently working on the data structure to support editing. I was studying the old format with what I think was B-tree inside xml doc until I read the articles about 3.0 yesterday. It is a lot easier to reverse. But one thing I ask out of Curiosity, what is with the encoding for the block files? It looks like the samples are aligned in some pattern. If you drop the output of these files into HxD for example.

It’s like this with spacing increasing linearly

s1.s2

s100..s101

s200...s201

If you unpack these bytes as 32 bit float and graph the samples it looks like audio data. But if I multiply each sample by 32767 and throw on a wav header it sounds like the bytes are offset(very horrible noise you don’t want to be familiar with). So is there more going on in a blockfile than just raw audio data? If so why?

>>>>> 

 

I've tried it with a simple two-track project and here's what I've been able to find:

- The data is indeed written as standard 32-bit IEEE float.

- To find the start of the first sample, I had to skip an odd number of bytes, which meant that when loading the file as raw data (including all the headers), the number of skipped bytes had to be one more than a multiple of 4.

-That's why many editors are unable to play it correctly because, for 32-bit data, they only allow skipping a number of bytes that is a multiple of 4.

- Surprisingly, when data from one track finish and data from another track begin, the byte offset changes. Therefore, when I skipped one byte, the first track sounded okay. When I skipped 0 bytes (i.e. loaded the entire thing), the second track sounded okay.

-From that I'm gathering (not verified yet but I can do that if someone desires) that if my project had one more track, it would probably load correctly if I chose to skip 3 bytes.

 

Petr

 

 

 


 <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 

Bez virů.  <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> www.avg.com