Optimierung von Pixel

[EWeiss]

Zitat von Medium:

Zitat von EWeiss:

Die neue von Medium liefert auch nicht das richtige Zeichnungs Resultat.

Leider bleibt "Channel" bei mir immer 0, daher kann ich nicht selbst testen. Inwiefern ist das Ergebnis falsch? (Ich frage aus persönlichem Interesse, nicht weil ich dir nicht glaube )
Ist es trotz falsch dennoch flotter?

Das Zeichnen des Spectrum schlägt fehl nicht so wie bei deiner ersten Version.
Die Läuft top.

Habe jetzt mit der Änderung bei der Progressbar von 31 Sec auf 14 runterschrauben können mit der 35MB Mp3

Zitat:

Die Farben sind irgendwie anders.

Ja habe ich auch bemerkt abhängig davon was ich verwende Pixel/ScanLine.
Dachte erst das läge am 24 BIT Format aber das ist ja bei beiden gleich.

Zitat:

Leider bleibt "Channel" bei mir immer 0

Schade kann man nichts machen. (Soundkarten\Treiber oder Einstellungs-Problem) denk ich mal.

Zitat:

aber das Buffer Array ist nur 160 Bytes groß.

Ja die Höhe des Bitmap -1

gruss

[Zacherl]

Zitat von EWeiss:

Zitat:

aber das Buffer Array ist nur 160 Bytes groß.

Ja die Höhe des Bitmap -1

Genau das verursacht einen schönen Buffer Overflow, weil BASS_ChannelGetData mit BASS_DATA_FFT512 trotzdem 256 Floats einliest, der Buffer aber nur Platz für 159 Stück hat.

[EWeiss]

Zitat von Zacherl:

Zitat von EWeiss:

Zitat:

aber das Buffer Array ist nur 160 Bytes groß.

Ja die Höhe des Bitmap -1

Genau das verursacht einen schönen Buffer Overflow, weil BASS_ChannelGetData mit BASS_DATA_FFT512 trotzdem 256 Floats einliest, der Buffer aber nur Platz für 159 Stück hat.

Ja nur wie will man das händeln man könnte BASS_DATA_FFT256 verwenden nur dann wären es zu wenig Floats.
Oder aber das Bitmap in der höhe entsprechend anpassen.

Nebenbei nach deiner Änderung sind Pixel/ScanLine fast identisch.. beide 14 Sec
Einen gewinn Zuwachs habe ich im Moment bzg. ScanLine noch nicht.

Pixel := 13:78
ScanLine := 14:60

Sogar langsamer..

gruss

[Medium]

Zitat von EWeiss:

Zitat von Zacherl:

Zitat von EWeiss:

Zitat:

aber das Buffer Array ist nur 160 Bytes groß.

Ja die Höhe des Bitmap -1

Genau das verursacht einen schönen Buffer Overflow, weil BASS_ChannelGetData mit BASS_DATA_FFT512 trotzdem 256 Floats einliest, der Buffer aber nur Platz für 159 Stück hat.

Ja nur wie will man das händeln man könnte BASS_DATA_FFT256 verwenden nur dann wären es zu wenig Floats.
Oder aber das Bitmap in der höhe entsprechend anpassen.

Oder den Buffer zwar so groß machen wie ihn die Bass.dll befüllt, aber weniger daraus lesen. Du hast dann zwar "zu viele Daten", aber die Bass.dll schreibt dir nicht in undefiniertem Speicher herum. Definitv die bessere Wahl. (Und verlieren tust du auch nichts, da du ja auch mit dem kleineren Buffer letztlich Daten einfach weg lässt. Nur mit dem zusätzlichen Effekt, dass du nicht sicher sein kannst, dass die weg gelassenen Daten, die die Bass.dll ja trotzdem schreibt, nicht irgendwelche anderen Dinge zersägt. Bisher hattest du im Grunde nur Glück, dass das gut ging.)

Wenn du alle Daten der FFT in 160 Pixeln Höhe anzeigen willst, musst du entweder die Daten oder das Bitmap skalieren. Anders gehts dann nicht.

[EWeiss]

Zitat:

Oder den Buffer zwar so groß machen wie ihn die Bass.dll befüllt, aber weniger daraus lesen.

Das tue ich ja auch
Ich lese ja nur soviel Pixel wie das Bitmap in der Höhe ist
for i := 0 to BUFFER_SIZE - 1 do

Daher verstehe ich auch nicht wie da ein Buffer Overflow entstehen sollte.

gruss

[Medium]

Du übergibst deinen zu kurzen Buffer mit BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512); in die Obhut der Bass.dll, und sagst ihr: "Hallo Bass.dll, bitte fülle diesen Buffer mit den FFT Daten eines 512 Byte langen Samples.". Die Bass.dll sieht nur einen Pointer auf ein Stück speicher, und glaubt dir blind, dass du genug Speicher für all die Werte die sie nun schreiben will reserviert hast, und legt los alle 512 Werte zu schreiben.
Aber du hattest eigentlich nur 160 Bytes für den Buffer reserviert. Was eventuell hinter deinen 160 Bytes steht, weiss maximal der Speichermanager. Aber weder du noch die Bass.dll wissen das. Es wäre nichts ungewöhnliches, wenn dort z.B. die Daten für einen der Buttons in deinem Programm lägen o.ä., und die Bass.dll würde die dann einfach so ungeprüft übernageln. Was das mit dem Verhalten von dem Button anstellt, ist vermutlich klar.
Dein Lesen ist nicht das Problem.

[Zacherl]

Zitat von EWeiss:

Daher verstehe ich auch nicht wie da ein Buffer Overflow entstehen sollte.

Hier SetLength(Buffer, BUFFER_SIZE); // Reserviert Speicher für 159x Single/Float und hier BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512); // Schreibt 256x Single/Float in den Buffer

[Medium]

Zitat von Zacherl:

Zitat von EWeiss:

Daher verstehe ich auch nicht wie da ein Buffer Overflow entstehen sollte.

Hier SetLength(Buffer, BUFFER_SIZE); // Reserviert Speicher für 159x Single/Float und hier BASS_ChannelGetData(Channel, Pointer(Buffer), BASS_DATA_FFT512); // Schreibt 256x Single/Float in den Buffer

Schreibt das nicht sogar 512 Bytes? Die letzten 256 sind zwar eine Spiegelung der ersten, aber eigentlich gehören sie dazu. Ich weiss nicht genau wie die Bass.dll das handhabt. Aber 160 Bytes sind definitv zu wenig, egal wie.

[EWeiss]

Zitat von Zacherl:

Zitat von EWeiss:

Daher verstehe ich auch nicht wie da ein Buffer Overflow entstehen sollte.

Schreibt 256x Single/Float in den Buffer[/DELPHI]

korrekt!

Aber ich verwende davon nur 160 Floats.
Es dürfte doch kein Problem sein aus einem Array nur so viele Einträge zu verwenden wie man sie benötigt
vorausgesetzt ich verwende nicht mehr wie enthalten sind.

wo entsteht bei dieser Konstellation ein Überlauf ?

Zitat:

Schreibt das nicht sogar 512 Bytes? Die letzten 256 sind zwar eine Spiegelung der ersten

Nein


gruss

[Uwe Raabe]

In deinem Fall kann Scanline seinen eigentlichen Vorteil gar nicht richtig ausspielen. Mit ScanLine kann man sehr schnell eine ganze Zeile des Bitmaps bearbeiten. Dein Code arbeitet aber spaltenorientiert, weswegen du immer nur ein Pixel der jeweiligen Scanline änderst und beim nächsten Aufruf bereits eine andere Scanline brauchst.

Eventuell kannst du noch etwas Performance herausholen, wenn du die Scanlines cached:

Delphi-Quellcode:

var
  ScanLines: TArray<PRGBTriple>;


  { nach Zuweisung von Bitmap.Height werden die Scanlines im Array mit der ersten Spalte initialisiert }
  SetLength(ScanLines, BitMap.Height);
  for I := 0 to Length(ScanLines) - 1 do begin
    ScanLines[I] := Bitmap.ScanLine[I];
  end;

  { statt SetPixel }
  aColor := HSLtoRGB(H, S, L); // hier könnte man noch etwas herausholen, wenn direkt die RGB-Werte zurückgegeben werden.
  P := ScanLines[BUFFER_SIZE - i];
  P^.rgbtRed := GetRValue(aColor); // dann spart man sich hier wieder das auslesen
  P^.rgbtGreen := GetGValue(aColor);
  P^.rgbtBlue := GetBValue(aColor);

  { nach Inc(ColumnCounter) werden die ScanLine-Pointer um eine Spalte weiter gerückt. }
  for I := 0 to Length(ScanLines) - 1 do begin
    Inc(ScanLines[I]);
  end;

Vorausgesetzt, es gibt eine Prozedur procedure HSLtoRGB(H, S, L: double; out R, G, B: Byte); könnte der relevante Code etwa so aussehen:

Delphi-Quellcode:

  SetLength(ScanLines, BitMap.Height);
  for I := 0 to Length(ScanLines) - 1 do begin
    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;
      P := ScanLines[BUFFER_SIZE - i];
      HSLtoRGB(H, S, L, P.rgbtRed, P.rgbtGreen, P.rgbtBlue);
    end;
    for I := 0 to Length(ScanLines) - 1 do begin
      Inc(ScanLines[I]);
    end;
    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;

Wenn nicht schon geschehen, solltest man auch mal die Basiszeit der Analyse ermitteln, die sowieso verbraucht wird ohne in das Bitmap zu schreiben.