Hello.

Is it possible to add a array of float into ressource ?

For example, there is myarray : array of cfloat.

Is it possible to store that array myarray ressource and, when I want to use it from ressource, I get also a array of float ?

In wiki : http://wiki.freepascal.org/Lazarus_Resources tey speak only how to add files into ressource.

Thanks.

Fre;D

-----
Many thanks ;-)

use

it from ressource, I get also a array of float ? In wiki : http://wiki.freepascal.org/Lazarus_Resources tey speak only how

to

add files into ressource.

No, you can't. Resources are not intended for this.

What are you trying to achieve?

Regards,
Sven

What are you trying to achieve?

Hello and thanks for answer.

Huh, I realize that what I ask is stupid.

Of course that array of float must be saved into file to be insered as ressource.

I want to save a buffer of audio samples (a array of float) and use that saved file as ressource for a other program.

That other program will use that ressource that will be converted back into a buffer of audio samples (array of float).

That is what I have now and that I envisage to do (but how?).

But perhaps, I am open for all, the use a tmemorystream in place of the buffer of audio samples would be easier and will spare a conversion (array of float ---> bytes).

Last but not least, does it exist a way to compress a array of float (or the result in bytes).

Many thanks.

Fre;D

-----
Many thanks ;-)

Hello.

I have saved the buffer into file with a TFileStream.

With lot of success for array of cint16 and cint32.

But for array of cfloat --> much less success.

Could it be that TFileStream does accept only integers as data ? If yes, a conversion would be needed ?

Something like: ?

for x := 0 to length(floatbuffer) -1 do
  begin
   floatbuffer[x] := round(floatbuffer[x] * 2147483647);
   if floatbuffer[x] > 2147483647 then floatbuffer[x] := 2147483647;
   if floatbuffer[x] < -2147483647 then floatbuffer[x] := -2147483647;
  end;

Thanks.

Fre;D

-----
Many thanks ;-)

Define "much less success". How are you writing the array and how are you reading it?

Could it be that TFileStream does accept only integers as data ? If yes, a conversion would be needed ?

One can write and read any blob of data with the stream classes if one knows what one is doing.

Regards,
Sven

Define "much less success". How are you writing the array and how are you reading it?

Hello and thanks for answer.

Here how the array is written:

var
buffer : array of float;
....
FileBuffer.Data := TFileStream.Create(filename,fmCreate);
FileBuffer.Data.Seek(0, soFromBeginning);
FileBuffer.Data.WriteBuffer(buffer[0],Length(Buffer));

The result is OK if integer 16/32 bit inside the buffer. If data inside the buffer is float 32 bit, result is a file of... 2 octets...

Thanks.

Fre;D

-----
Many thanks ;-)

You must write

  FileBuffer.Data.WriteBuffer(buffer[0],Length(Buffer)*Sizeof(Float));

Because for a dynamic array, length returns the length in elements, not in bytes.

Michael.

Hello Michael and thanks for answer.

You must write FileBuffer.Data.WriteBuffer(buffer[0],Length(Buffer)*Sizeof(Float));

Ha, perfect, many thanks.

But there is something that I do not catch, why is it working for integer ?

Sizeof Integer is 2 bits so, normally:

FileBuffer.Data.WriteBuffer(buffer[0],Length(Buffer));

should not work (but it works) ---> Length(Buffer) = 1/2 * Length(Buffer)*Sizeof(integer)

?

Fre;D

-----
Many thanks ;-)

I don't know. By all logic, it should not work either.

Michael.

I don't know. By all logic, it should not work either.

Yes, it is I think too.

Some more explanation:

I use a "global" buffer of float to store data.
Those data can be int16, int32 or float32.

For example,

If data are integer (16 or 32 bit), I do:

bufferfloat[x] := 127.0 ; (for int16)
bufferfloat[x] := 2147483646.0; (for int32)

If data are float 32 bit, I do:

bufferfloat[x] := 0.2147483646 ; (for float32)

So it seems to me Sizeof(bufferfloat[x]) is the same in the 3 cases (alway sizeof(float)).

Aaargh, sorry, I always come with extreme programming (or extreme dummy) question.

Fre;D

-----
Many thanks ;-)

Of course it's always the same size as it's an array of cfloat after all and no assignment will change that.

Regards,
Sven

I don't know. By all logic, it should not work either.

OK, It comes from a "lucky" bug (thanks to reveal it). There was a setlength(buffer, length(buffer) * channels) not needed.

Ok, fixed.

But the problem remain:

If data are int16 or int32: OK, the file is created with +- 1 mega bytes and I can get those data back.

But if data are float32: NOT OK, the file is created but with only 6 octets ;-( .

For example,

for x :=0 to length(bufferfloat) -1 do
bufferfloat[x] := 127 ; // for int16 ---> it works
for x :=0 to length(bufferfloat) -1 do
bufferfloat[x] := 2147483646;  // for int32 ---> it works
for x :=0 to length(bufferfloat) -1 do
bufferfloat[x] := 0.2147483646 ; // for float32 ----> it does not work

Fre;D

-----
Many thanks ;-)

Looks like for float you'd need a conversion record

{enable packed records}

TFloatToBuffer = packed record
  case boolean of
    true: FloatField : float32;
    false : BufferField : array[0..3] of byte;
  end;
end;
for x := 0 to length(bufferfloat)-1 do
  bufferfloat[x].FloatField := {float value}
// but then special handling is likely needed to concat the buffer to write to file and reading from file
// so be careful ;)

-L.

If the bufferfloat is the same variable in all cases, there should be no difference whatsoever. The write operation doesn't care a fig about the actual contents of the buffer.

Michael.

There should be absolutely no need for that ?

Michael.

Or, quite comically maybe: use a text file... write/writeln and read/readln, and use zip compression on the text file to compress data...

-L.

Sent from the Free Pascal - General mailing list .

Or, quite comically maybe: use a text file

Or maybe, like in my second post, convert float32 ---> integer32

for x := 0 to length(floatbuffer) -1 do
  begin
   floatbuffer[x] := round(floatbuffer[x] * 2147483647);
   if floatbuffer[x] > 2147483647 then floatbuffer[x] := 2147483647;
   if floatbuffer[x] < -2147483647 then floatbuffer[x] := -2147483647;
  end;

And do the reverse when reading from the file ?

Fre;D

-----
Many thanks ;-)

I don't know what you're doing wrong, but the following works:

=== code begin ===

program tfloatbuf;
{$mode objfpc}
uses
  SysUtils, Classes, ctypes;
var
  fbuf: array of cfloat;
  i: LongInt;
  fs: TFileStream;
begin
  SetLength(fbuf, 42);
  for i := Low(fbuf) to High(fbuf) do
    fbuf[i] := 3.1415;
  Writeln('Writing data to ', ParamStr(1));
  fs := TFileStream.Create(ParamStr(1), fmOpenWrite or fmCreate);
  try
    fs.WriteBuffer(fbuf[0], Length(fbuf) * SizeOf(fbuf[0]));
  finally
    fs.Free;
  end;
  SetLength(fbuf, 0);
  SetLength(fbuf, 42);
  Writeln('Reading data from ', ParamStr(1));
  fs := TFileStream.Create(ParamStr(1), fmOpenRead);
  try
    fs.ReadBuffer(fbuf[0], Length(fbuf) * SizeOf(fbuf[0]));
  finally
    fs.Free;
  end;
  for i := Low(fbuf) to High(fbuf) do
    Writeln(fbuf[i]);
end.

=== code end ===

Regards,
Sven

I don't know what you're doing wrong, but the following works:

Huh, it is exactly what I (think to) do.
And re-reading hundred times my code does not see any difference.

OK, I will re-read thousand times the code, maybe I will find what is wrong.

Many thanks for your code Sven.

Fre;D

-----
Many thanks ;-)

wrong.

Then try to minimize your code as much as possible and then show it here (an as small as possible compileable example that shows your problem).

Regards,
Sven

Re-hello.

Ok, I do not find yet the guilty in my code, I will re-try a other day. By the way, your code is working perfectly Sven.

Now, last part of the question: how to convert that file stored into ressource but without to write to the disk (only memory stream)?

A TFileStream could be used but it needs a path.
And in ressource there is no path to use in
TFileStream.Create('/the/path/filename', fmOpenRead);

What could be the solution ?

Fre;D

-----
Many thanks ;-)

To access a file stored as a resource you need to use TResourceStream.

Regards,
Sven

To access a file stored as a resource you need to use TResourceStream.

Ho my Dog, I did not know this one.
More than perfect, many thanks Sven.

PS: About array of float into TFileStream, after Googling a while, it s not possible to do directly like fpc does for C compilers. You need a conversion (like explained by Lukasz Sokol). And it is the reason why I am (once again) very impressed by fpc.

Many thanks Sven for your help.
Do you agree if I add your name into the list of the "great contributors" of uos (https://github.com/fredvs/uos) ?

Fre;D

-----
Many thanks ;-)

not

possible to do directly like fpc does for C compilers. You need a conversion (like explained by Lukasz Sokol). And it is the reason why I am (once again) very impressed by fpc.

Huh? Of course you can do that rather similary in C as well.

Many thanks Sven for your help. Do you agree if I add your name into the list of the "great contributors"

of

uos (https://github.com/fredvs/uos) ?

I don't think that's necessary. I'm merely doing my "job"...

Regards,
Sven

Indeed. You can do exactly the same. You can do this:

{$mode objfpc}
uses classes;
Type
   Float = Double;
   TFloatArray = Array of Float;
Procedure TestRW(X : TFloatArray);
Var
   F : TFileStream;
   Y : TFloatArray;
   I : Integer;
begin
   // Write
   F:=TFileStream.Create('float.dat',fmCreate);
   try
     F.WriteBuffer(X[0],Length(X)*SizeOf(Float));
   finally
     F.Free;
   end;
   // Read
   F:=TFileStream.Create('float.dat',fmOpenRead);
   try
     SetLength(Y,F.Size div SizeOf(Float));
     F.ReadBuffer(Y[0],F.Size);
   finally
     F.Free;
   end;
   // Check
   If Length(Y)Length(X) then
     Writeln('Wrong length')
   else For I:=0 to Length(X)-1 do
     if (X[i]Y[i]) then
       Writeln('Wrong element at pos ',i,': ',X[i]Y[i]);
end;
var
   X : TFloatArray;
   I : Integer;
begin
   SetLength(X,10);
   Writeln('Floats');
   For I:=0 to Length(X)-1 do
      X[i]:=10+(1/(1+I));
   TestRW(X);
   Writeln('integers');
   For I:=0 to Length(X)-1 do
      X[i]:=10+I;
   TestRW(X);
end.

Michael.

Hi,

so here is what I am seeing in Fre;D's code, that he managed to paste in one of the previous messages :

// "FileBuffer.Data.Seek(0, soFromBeginning);"
      F.Seek(0, soFromBeginning);   /// this it would be in Michaels' code
I don't think it matters if you newly create the stream...
looks like something (probably) performed by the constructor already;

(just a stab in the dark here, unless we take the time to look into Fred's github ?)

-L.

OK, I understand. (But I ask it always when I get great help, it is a matter of conscience and respect.)

> Huh? Of course you can do that rather similary in C as well. Indeed. You can do exactly the same. You can do this:

Huh in C, in one shot, like fpc does, without conversion and working?

(just a stab in the dark here, unless we take the time to look into Fred's github ?)

The code of uos_AddFromRessource(...) is not yet committed, I have to clean and control all before, but, of course it will be a great honor if you take a look in uos code.
And mainly if you find something wrong in the main loop or in the concept of uos.

For example, I got a advice that some data of uos are reference counted and that is bad.
OK, but how to know if data are reference counted and why is it bad? (I did code for reference counted only for dynamic-loading of libraries).

A other advice was that is not good that each player is a thread. OK, but how could you make the main program-thread still work if players are not independent thread?

Voila.

PS: There is a uos forum here: http://uos.2369694.n4.nabble.com

Many thanks for your Sven, Michael and Lukasz.

Fre;D

-----
Many thanks ;-)

The following code reads the floatbuf.txt file that my Pascal example code generated and correctly prints 3.141500 42 times:

=== code begin ===

#include <stdio.h>
int main()
{
        float* floatbuf;
        FILE* file;
        file = fopen("floatbuf.txt", "rb");
        if (!file)
        {
                printf("Failed to open file\n");
                return 1;
        }
        floatbuf = malloc(sizeof(float) * 42);
        if (fread(floatbuf, sizeof(float), 42, file) != 42)
        {
                printf("Failed to read data\n");
                fclose(file);
                free(floatbuf);
                return 1;
        }
        for (int i = 0; i < 42; i++)
                printf("%f\n", (double)floatbuf[i]);
        fclose(file);
        free(floatbuf);
        return 0;
}

=== code end ===

Regards,
Sven

OK, Sven you win (and http://stackoverflow.com should follow fpc forum). But you will not convince me that c does better than fpc, maybe equal but surely not better.

Huh, saving a buffer of float into wav file format, with correct header, --->
loaded by audacity ----> horrible noise.

loaded by fpc (via uos) ----> perfet sound.

But is maybe because wav format accept only in theory data from float. (and that wav file are (nearly) always encoded from 32 bit integer and converted into float32).

But that is a other story.

Viva fpc.

Fre;D

-----
Many thanks ;-)

fredvs wrote

OK, Sven you win (and http://stackoverflow.com should follow fpc forum). But you will not convince me that c does better than fpc, maybe equal but surely not better.

Despite me definitely favoring Object Pascal as well, I can't you have spreading incorrect information on C, can I? ;)

Regards,
Sven

Hi,
 
there are different informations about *.wav, so maybe there are different impementations too. See:
http://soundfile.sapp.org/doc/WaveFormat/
and
https://blogs.msdn.microsoft.com/dawate/2009/06/23/intro-to-audio-programming-part-2-demystifying-the-wav-format/  
The first says that 8-bit is unsigned, the second says signed. The first does not mention floats, the second says 32-bits but only -1.0 to 1.0.  
V.
 
______________________________________________________________

OK, Sven you win (and http://stackoverflow.com <http://stackoverflow.com> should follow fpc forum). But you will not convince me that c does better than fpc, maybe equal but surely not better.

Huh, saving a buffer of float into wav file format, with correct header, --->
loaded by audacity ----> horrible noise.

loaded by fpc (via uos) ----> perfet sound.

But is maybe because wav format accept only in theory data from float. (and that wav file are (nearly) always encoded from 32 bit integer and converted into float32).

But that is a other story.

Viva fpc.

Fre;D

-----
Many thanks ;-)

Vojtěch Čihák wrote

Hi,

intersting,

This also has endiannes information, which is quite cool..

and https://blogs.msdn.microsoft.com/dawate/2009/06/23/intro-to-audio-programming-part-2-demystifying-the-wav-format/

and this one, seems to be saying the data and file size fields are 32 BYTES (emphasis mine) long.

-L.

Vojtěch Čihák wrote

there are different informations about *.wav, so maybe there are different impementations too. http://soundfile.sapp.org/doc/WaveFormat/ https://blogs.msdn.microsoft.com/dawate/2009/06/23/intro-to-audio-programming-part-2-demystifying-the-wav-format/

Hello,

Wav (AKA RIFF WAVE) is a container (RIFF), not an audio format, inside a wav you can put many audio formats and other informations like author, copyright, cues, some of them standard (defined by Microsoft) and others proprietary.

Usual wav files that most people use are PCM (Pulse Code Modulation) or in more programmer words int16 per channel. This is the usual format, but you can put inside floats, mp3, GSM, ADPCM, and many more.

@Fredvs: If your wav is noise in audacity the reason is quite sure because you are writing float audio buffer with a wav PCM header. Wav PCM is 4 bytes per sample in stereo while float is 8 bytes and almost never used for wav. Header and audio data (format, channels, bit depth) must match.

The first says that 8-bit is unsigned, the second says signed. The first does not mention floats, the second says 32-bits but only -1.0 to 1.0.

Hello.
Yes wav is nebulous and this site:

http://stackoverflow.com/questions/2062620/how-to-write-wav-file-with-32-bit-float-data

says it must set the wFormat tag in the 'fmt' chunk to WAVE_FORMAT_IEEE_FLOAT (3).

I have try but this does not work.

For recording, I will use a "custom" pcm format, using array of float (because with fpc we are not afraid to use float).

Thanks for infos.

@Fredvs: If your wav is noise in audacity the reason is quite sure because you are writing float audio buffer with a wav

Ho, it is not a problem, I knew that wav file prefer integers. It was to see what Audacious has in his body.
For example, with Audacious you can export wav only as 16 bit.

But, now that I have full access to the samples, that fpc deals perfectly array of float in TFileStream, there is no more reason to save the recording into wav format. I will use my own one. 32 bit float.

I can't you have spreading incorrect information on C, can I? ;)

Maybe but what I think is that C people always want to make things complicated.
And they should, IMO, sometimes think more "Pascalish". The code of Sven is a perfect example.
He gives the easy-working solution in Pascal code and then translate the pascal code into C.
And it works for c. And all other c solutions I did found on the web were complicate-not-clear-not-working solutions, with lot of conversions. If they could take a look at Sven code ---> 3 lines and it works.

Fre;D

-----
Many thanks ;-)

can't you have spreading incorrect information on C

Hello.

Some more infos about the problem of our C friends

It seams that for C compilers (Clang, gcc, c++, VS,...) the way to order the data with a TFileStream differs (not same x-endians) for encoding float.

So you must do it by code and know what compiler was used for the client-program .

For a file created with a TFileStream of gcc but that will be used by a program compiled with VS, you should
convert the data from little endian to native ordering (or reverse) with something like:

        for i := 0 to nSamples-1 do
        b egin
          PCMIn[i] := (pcm_bytes[2*i+1] shl 8) or pcm_bytes[2*i];
        end;

And this the reason why, for storing data, they prefer to use integer 32 bit (where it seams that all compilers use the same order).

Voila.

But it is not our problem, so thank for everything and good luck to our C friends and their endians.

Fre;D

-----
Many thanks ;-)

This has nothing to do with C compilers or with 16 vs 32 bit numbers. At most, it will be different on little and big endian platforms, just like with FPC. However, there are both little and big endian PCM 16 bit formats.

Jonas

This has nothing to do with C compilers or with 16 vs 32 bit numbers.

Ha, ok.
Then I do not understand why C developers are afraid to store float data.

;-)

Fre;D

-----
Many thanks ;-)