Jaki tu jest bląd bo ta procedura nie dziala (ale sie kompiluje).
procedure odczyttagow(sciezka:string);
var
plik:tfilestream;
bufor:array[1..3]of char;
begin
filemode:=0;
plik:=tfilestream.Create(sciezka,fmopenread);
try
plik.Seek(3,plik.Size-128);
plik.ReadBuffer(bufor,3);
finally
plik.free;
end;
label1.caption:=bufor;
else
end;
Wiem: pewnie to blachy problem ale ja tego nie potrafie.
plik.Seek(plik.Size-128, sofrombeginning);
// Pierwszy parametr mówi, o jaką ilość bajtów ma przeskoczyć wskaźnik pliku, natomiast drugi mówi, od jakiej pozycji ma zacząć liczyć. Jak nie wierzysz, to spojrzyj do helpa. Poza tym, tak trudno się domyślić, mając gotowy kod?
Możesz ta wyjasnić. W artykule "Strumienie" napisane jest że pierwszy parametr polecenia seek to wielkośc danych a drugi to miejsce z którego ma się zacząć operacje.
Moim zdaniem niepotrzebnie używasz fileStream. W serwisie jest gdzieś gotowy kod o odczycie tag v1, a osobiście napisałem artykuł z przykładowym kodem o odczycie tagv2. Oczywiście mój sposób jest trochę skomplikowany i teraz opracowuję bardzo łatwy.
Wiem czytalem twoj artykul ale trudno go przystosowac do mojego programu. A poza tym po co mam przepisywać kod. Robie ten program żeby sie czegos nowego nauczyc.
Wiem czytalem twoj artykul ale trudno go przystosowac do mojego programu. A poza tym po co mam przepisywać kod. Robie ten program żeby sie czegos nowego nauczyc.
I bardzo dobrze :)
To więc podpowiem Ci o ID3Tag v1.
Najpierw dowiedz się, jak jest tworzony.
Powiem Ci pokrótce, ze zajmuje 128 ostatnich bajtów pliku.
Składa się z: identyfikator, autor, tytul, rok, komentarz, rodzaj.
Identyfikator to: "TAG", autor, tytul, komentarz zajmuja po 30 bajtow, a rodzaj 1 bajt. Natomiast rok 4 bajty. Wszystko oprocz rodzaju jest stringiem.
Jeszcze musisz wiedzieć jaka jest kolejność, ale to wystarczy, że popatrzysz na jakiś mp3 z tym tagiem.
Podpowiem Ci jeszcze, żebyś nie używał do tego celu fileStream, jeno file po protu:
var
plik: file;
Wielkim udogodnieniem jest to, że jest stała pozycja tagów, tzn., że każdy jego element ZAWSZE zaczyna się w tym samym bajcie tagu.
Jak chcesz czegoś wiecej, to pisz na priv
Jest <ort>jusz </ort>wszystko elegancko. odczytuje tagi ale przy niektórych są takie kwadraty puste w środku. co to jest??
- ŁFJak to takie oczywiste to odpowiedz
// pierwszy raz takie "kwadraciki" widzisz? 1) to znak #0, którego w plikach binarnych jest mnóstwo, i który przy okazji oznacza koniec łańcucha ASCIIZ. 2) każda czcionka windowsowa ma obowiązek zawierać znaki ASCII (#32..#127), i na tym koniec. pozostałe znaki zależą od konkretnej czcionki. brak konkretnego znaku w czcionce = kwadracik.
Domyśliłem sie ale dlaczego w niektórych to wystepuje na koncu a w innych nie (czasami cały tag ma tylko to)?
Bo jeśli wielkości poszczególnych pól sa stałe, a długość ich zawartości - różna, to chyba logiczne, że czymś trzeba wypełnić luki.
Jest <ort>jusz </ort>wszystko elegancko. odczytuje tagi ale przy niektórych są takie kwadraty puste w środku. co to jest??
Słuchaj. Zanim odczytujesz TAG, to upewnij się, że on istnieje.
Np: if tag.id='TAG' then dalej odczytuj Tagi
Poza tym najprościej jest odczytać cały łańcuch(ostatnie 127 bajtów), a potem dzielić to na poszczególne tagi(copy)
I tak jak powiedział mój poprzednik. Tagi mają swoje stałe miejsce. Nie znam kolejności na pamięć, ale powiedzmy, że jest: ID, Autor, Tytul, Album, Komentarz, rok i jeżeli np. nie ma komentarza, MOŻE towyglądać tak:
TAGAUTOR TYTUŁ ALBUM
##############################1994
Oczywiście # to kwadraciki. Mogą one być, a może też być zupełnie co innego, tak samo jak po prostu puste spacje
Ale w niektórych tego nie ma. Jest chyba standard v1 i v1.1. Czy to jest przyczyną?
Ale w niektórych tego nie ma. Jest chyba standard v1 i v1.1. Czy to jest przyczyną?
Nie wiem. Wiem, że w niektórych jest tag, w niektórych są spacje, a w niektórych "kwadraciki"