TAudio- play, edit, convert audio files

[Tomxe]

1) No DLLs required, no external programs
2) Can play, edit and convert audio files
3) Output format is currently only WAV
4) License: MIT

https://github.com/Xelitan/TAudio---audio-library-in-pure-Pascal/

Usage example:

Code: Pascal  [Select][+][-]

1.   if not OpenDialog1.Execute then Exit;
2.  
3.   a := TAudio.Create;
4.   a.LoadFromFile(OpenDialog1.Filename);
5.   a.SaveToFile('output.wav');
6.   a.Free;

[wp]

It's interesting to see an audio lib written in pure Pascal. But, since the audio is played by MMSystem's sndSoundPlay, it is windows-only -- if you put the "Play" and "Stop" methods as well as the MMSystem unit into a define {$IFDEF MSWINDOWS} it will be cross-platform, though.

Find in the attachment a small demo reading a wav and an mp3 file and displaying the samples in a chart. There seems to be an issue with the FFrame values which are not correctly signed (they should be declared as SmallInt rather than LongInt).

[Tomxe]

How can audio be played on Linux using only Lazarus built-in functions?

[TRon]

How can audio be played on Linux using only Lazarus built-in functions?

You don't. Same for every other platform unless the hardware contains the audio-device out of the box.

[Tomxe]

There seems to be an issue with the FFrame values which are not correctly signed (they should be declared as SmallInt rather than LongInt).

Instead of your Alarm01.wav I tested on your mp3 file converted to wav (attached). And looks fine on the graph.

[wp]

Because the demo that I had posted worked around the issue. Modify the i loop in Button1Click as follows to remove the workaround:

Code: Pascal  [Select][+][-]

1.     for i := 0 to High(audio.FFrames) do
2.       with audio do
3.       begin
4.         t := i / FSampleRate;
5. //        yL := DecodeFrame(FFrames[i].Left);
6. //        yR := DecodeFrame(FFrames[i].Right);
7.         yL := FFrames[i].Left;
8.         yR := FFrames[i].Right;
9.         LeftChannelSeries.AddXY(t, yL);
10.         RightChannelSeries.AddXY(t, yR);
11.       end;

With this modification the plot of the Alarm01.wav looks as shown in the attached screenshot (and similarly for your converted sample-3s.wav). And when you zoom in you see that the negative part of the wave is shifted up to 65535. Basically this is because the file has a sample size of 16bits, and you read each sample by calling the GetU2 method of the reader. You assign the obtained word variable to the longint of the FFrames left/right channel - and this destroys the sign of the values: a $FFFF (-1) in the file becomes $0000FFFF in the FFrames (65535).

You can fix this by reading 16-bit sample files by calling the GetI2 method which reads the file values into 16-bit signed smallints and thus keeps the sign.

Code: Pascal  [Select][+][-]

1. function TAudioWav.LoadFromStream(Str: TStream): Boolean;
2. ...
3.   else if FHandle.FSampleSize = 16 then begin
4.     for i:=0 to NumFrames-1 do begin
5.       FHandle.FFrames[i].Left := r.GetI2; //r.getU2;
6.       if NumChannels>1 then
7.         FHandle.FFrames[i].Right := r.GetI2; //r.getU2;
8.     end;
9.   end
10. ...

Probably the same change needs to be made for the other GetU* calls in TAudioWav.LoadfromStream and probably also in the other file format readers. But I did not check this.

[minesadorada]

Sometimes a clever solution is too clever.

My component PlaySound under Linux simply polls all the various native sound players until it finds one that works.
This is old-style programming