Optimierung von Pixel

[Uwe Raabe]

Zitat:

Zitat von EWeiss (Beitrag 1335113)

Seite 4

In der Spectrogram_08_04_16.rar ist aber keine MP3 vorhanden.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1335115)

Zitat:

Zitat von EWeiss (Beitrag 1335113)

Seite 4

In der Spectrogram_08_04_16.rar ist aber keine MP3 vorhanden.

Ach so ich meinte eigentlich deine Quelltext Änderungen ob du diese mit meinem Example getestet hast
nach deinen Änderungen in dem Quellcode.

OK.
Ich habe es mal selbst gemacht.
Und hänge deine Änderungen mal an.
Ein Problem habe ich noch.
Warum akzeptiert ScanLine keinen Buffer von 256?

Delphi-Quellcode:

BUFFER_SIZE = 256;

funktioniert mit Pixel aber nicht mit ScanLine.
Dort muss ich den Buffer mit 255 definieren.

PS:
Nach deinen Änderungen
Mariah Carey - Breakdown.mp3 320k, 10,8 MB
Pixel 05:72 sec
ScanLine 02:41 sec

Das ist doch schon mal was und man sieht einen merkbaren Unterschied.

gruss

[EWeiss]

Aktueller Test.. Denke diese ScanLine Optimierung von Uwe ist bisher die beste.

Alt: erster Versuch

Das analysieren einer MP3 "Pink Floyd - Echoes"

1. Zeit: 00:16:30
2. Größe: 37 MB
3. Frequenz: 44k1
4. Bitrate: 320k

ScanLine: 109138 ticks
Pixel: 109404 ticks

Letzte: Optimiert von Uwe

1. Zeit: 00:16:30
2. Größe: 37 MB
3. Frequenz: 44k1
4. Bitrate: 320k

ScanLine: 7971 ticks 07:97 sec
Pixel: 19500 ticks 19:50 sec

Das ist doch schon mal ein Riesen fortschritt.

Delphi-Quellcode:

  SetLength(Buffer, BUFFER_SIZE);
  ColumnCounter := 0;

  start := GetTickCount;

  if RadioButton1.Checked then
  begin
    SetLength(ScanLines, Bitmap.Height);
    for i := 0 to Length(ScanLines) - 1 do
      ScanLines[i] := Bitmap.Scanline[i];
  end;

  while BASS_ChannelIsActive(Channel) <> BASS_ACTIVE_STOPPED do
  begin
    BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512);
    for i := 0 to BUFFER_SIZE - 1 do
    begin
      Value := SQRT(SQRT(Buffer[i]));
      H := 0 + Value / 1.5;
      L := Value;

      if RadioButton1.Checked then
      begin
        P := ScanLines[BUFFER_SIZE - i];
        HSLtoRGB(H, S, L, P^.rgbtRed, P^.rgbtGreen, P^.rgbtBlue);
      end
      else
      begin
        HSLtoRGB(H, S, L, R, G, B);
        Bitmap.Canvas.Pixels[ColumnCounter, BUFFER_SIZE - i] := RGB(R, G, B)
      end;

    end;

    if RadioButton1.Checked then
    begin
      for i := 0 to Length(ScanLines) - 1 do
        Inc(ScanLines[i]);
    end
    else
      Inc(ColumnCounter);

    Progress := trunc(100 * (Bass_ChannelGetPosition(Channel, BASS_POS_BYTE) / BASS_ChannelGetLength
          (Channel, BASS_POS_BYTE)));

    if (Form2.ProgressBar1.position <> Progress) then
    begin
      Form2.ProgressBar1.position := Progress;
      PB.Refresh;
    end;
  end;

gruss

[Uwe Raabe]

Wenn du die Zuweisung auf Pixels auskommentierst und im Pixel-Mode laufen lässt, erfolgt gar keine Grafikausgabe. Das ist die untere Grenze für die Laufzeit. Die Differenz zu den Laufzeiten bei aktiver Grafikausgabe (Pixel oder Scanline) ist dann die eigentliche Zeit, die für die Grafikausgabe benötigt wird.

[EWeiss]

Zitat:

Zitat von Uwe Raabe (Beitrag 1335120)

Wenn du die Zuweisung auf Pixels auskommentierst und im Pixel-Mode laufen lässt, erfolgt gar keine Grafikausgabe. Das ist die untere Grenze für die Laufzeit. Die Differenz zu den Laufzeiten bei aktiver Grafikausgabe (Pixel oder Scanline) ist dann die eigentliche Zeit, die für die Grafikausgabe benötigt wird.

Bei ScanLine ohne Grafik habe ich 7 Sekunden und mit 9
dann benötige ich für die Grafik gerade mal 2 Sekunden.

Pixel mit Grafik 19 sec ohne 9
Hier sind es hingegen schon 10 Sekunden.

Man merkt auf jeden fall das sich etwas getan hat.

gruss

[386sx]

Ws st dnn 9?

[EWeiss]

Zitat:

Zitat von 386sx (Beitrag 1335122)

Ws st dnn 9?

steht doch da ohne Grafik

gruss

[Medium]

Zitat:

Zitat von EWeiss (Beitrag 1335110)

Fehler "Bereichsüberschreitung bei ZeilenIndex" wenn mein Buffer 256 groß ist.

Dann ist dein Buffer größer als das Bitmap hoch ist. (Oder du übergibst aus irgend welchen anderen Gründen eine Y-Koordinate ausserhalb des Bitmaps. Ohne konkreten Code schwer zu sagen.) Was diese Meldung sagt: "Du forderst eine Zeile im Bitmap an, die das Bitmap gar nicht besitzt." Also entweder eine Zeile < 0 oder >= Bitmap.Height.

Letztlich ist aber die Variante, die die Scanlines puffert, sicherlich schneller. Mich würde aber dennoch interessieren, wo das Problem mit meinem Vorschlag war, wo ein 1-zeiliges Bitmap gedreht ge-PlgBlt-ed wurde. Mangels Delphi kann ich das gerade nicht weiter testen, aber noch sehe ich mildes Potenzial darin.

[EWeiss]

Zitat:

Dann ist dein Buffer größer als das Bitmap hoch ist. (Oder du übergibst aus irgend welchen anderen Gründen eine Y-Koordinate ausserhalb des Bitmaps. Ohne konkreten Code schwer zu sagen.) Was diese Meldung sagt: "Du forderst eine Zeile im Bitmap an, die das Bitmap gar nicht besitzt." Also entweder eine Zeile < 0 oder >= Bitmap.Height.

Ok dann muss ich da nochmal durch und debuggen.
EDIT:
Ok es liegt daran weil die Schleife bei 0 anfängt und

Delphi-Quellcode:

ScanLines[BUFFER_SIZE - i]

nun mal 256 sind das hat zur folge das P dann nicht initialisiert wird und NIL ist.

muss halt auf NIL prüfen

Wie gesagt schade das der Channel bei dir 0 ist.

Zitat:

aber noch sehe ich mildes Potenzial darin.

Glaube ich dir gern..
Ich hatte Probleme bei der Grafik Darstellung kann natürlich auch daran liegen
das ich deinen Code falsch interpretiert habe und deshalb die Implementierung fehlgeschlagen ist.
Versucht habe ich es auf jeden fall :)

Zitat:

Die Bitmap muss gar nicht größer werden, nur der Buffer. Allerdings musst du dann die Schleife anders aufbauen

Verstehe ich nicht warum den Buffer vergrößern sind doch genug Daten enthalten die ich Rendern will also wenn das Bitmap 160 hoch ist.


gruss

[Medium]

Zitat:

Zitat von EWeiss (Beitrag 1335125)

Verstehe ich nicht warum den Buffer vergrößern sind doch genug Daten enthalten die ich Rendern will also wenn das Bitmap 160 hoch ist.

Nochmal: Nur weil du genau passend aus dem Buffer liest, heisst das nicht, dass die DLL auch passend rein schreibt. Stell dir die Funktion in der DLL grob so vor:

Delphi-Quellcode:

function GetData(aChannel, aMaxData, aPosition: Integer): Single;
begin
  ...
end;

procedure BASS_ChannelGetData(aChannel: Integer; buf: Pointer, aDataType: TBassDataType);
var
  i: Integer;
begin
  case aDataType of
    BASS_DATA_FFT256:
      for i := 0 to 127 do
        Single((buf+(i*4))^) := GetData(aChannel, 127, i);
    BASS_DATA_FFT512:
      for i := 0 to 255 do
        Single((buf+(i*4))^) := GetData(aChannel, 255, i);
    BASS_DATA_FFT1024:
      for i := 0 to 511 do
        Single((buf+(i*4))^) := GetData(aChannel, 511, i);
    ...
  end;
end;

Wenn du diese Funktion mit dem Parameter BASS_DATA_FFT512 aufrufst, werden immer zwingend 256 Single-Werte ab der Speicherposition des ersten Elementes deines Arrays geschrieben. Selbst wenn dein Array nur 1 Element lang wäre. Die Prozedur weiss nicht wie lang das Array ist, und geht - weil du mit BASS_DATA_FFT512 aufgerufen hast - davon aus, dass du dafür gesorgt hast, dass der Speicher lang genug reserviert ist.
Wenn dies nicht der Fall ist, liegen im Speicher hinter dem zu kurzen Array potenziell andere Variablen, möglicherweise sogar welche, die überhaupt nichts mit dem Programmteil zu tun haben, sondern vielleicht irgendwas in der VCL oder weiss der Geier. Die DLL würde diese dann ohne Gnade überschreiben, und wenn sie dann später mal gebraucht würden, knallt es. Auch wieder möglicherweise an komplett anderen Stellen, die keinen Rückschluss darauf zulassen, dass der eigentliche Fehler hier an dieser Stelle passiert ist.
Wenn man sich solche Schnitzer eingefangen hat, kann man in größeren Programmen Tage bis Wochen damit verbringen sie zu finden.

Anderes Thema:
----------------------------------
Ich habe erst jetzt realisiert, dass du ja gar nicht beim Abspielen "live" das FFT Bild malst, sondern vorab! Das eröffnet eine interessante Möglichkeit: Man könnte das Bild zunächst um 90° gedreht auf ein Puffer-Bitmap zeichnen, weil du damit dann nämlich schön alle Zeilen (lies: Scanlines) nacheinander durchgehen kannst, und nicht wie jetzt diese puffern und umherspringen musst. Das fertige Puffer-Bitmap zum Schluss dann mit PlgBlt() gedreht in das Image malen, und fertig. Das sollte ruck zuck gehen.
Leider hast du alle Anhänge gelöscht (wieso!?!?), so dass ich das nicht testweise bauen kann. Schade.