14 replies to this topic

[Denisdaf]

Hallo,

Als ik via de pc de harde schijf van de Vu's benader zie ik naast de *.TS bestanden nog andere bestanden in dezelfde folder staan.

Deze hebben de volgende extenties *.ap; *.cuts; *. eit; *.meta; en *. sc.

 

De vraag (of vragen) waartoe dienen ze, en wat als ik ze weghaal?

 

Ik heb ondervonden dat het niets met txt te maken heeft, want als ik de *.ts bestanden naar de pc breng kan ik zonder die andere de txt lezen.

Bewerken met videoredo kan ook zonder de aanwezigheid van die bestanden, vandaar dus de vraag.

 

Het is zekfs zo, dat al ik de bewerkte *s TS bestanden terug naar de HDD van de VU zet deze perfect weer te geven zijn met de VU.

[pluizebol]

Klopt

 

Ik bewerk ook TS en EIT files en save die terug naar de HDD

De andere files doe ik dan ook weg

[Denisdaf]

Klopt

 

Ik bewerk ook TS en EIT files en save die terug naar de HDD

De andere files doe ik dan ook weg

En waarom, en wat doe je dan met de EIT bestanden?

[pluizebol]

De EIT bestanden bevatten de inhoud/beschrijving van het opgenomen programma.

 

Ik heb er de volgende problemen mee :

 

Speciale leestekens zoals é è ç à enz worden (in mijn geval) weergegeven door zeer vreemde character-combinaties, en die herstel ik dan.

 

De EIT files geven een continu doorlopende tekst van inhoud, regisseur, deelnemers, enz.

Dat vind ik niet fijn als ik snel ff wil kijken waarover het gaat en wie er allemaal meespeelt in bijvoorbeeld een opgenomen film.

 

Die EIT files bewerk ik daarom soms/meestal met het PC-programma EITitor.

Dit kun je hier vinden : http://www.sat-unive...ad.php?t=101885

(De laatste versie is 1600 + patch.)

Edited by pluizebol, 18 January 2015 - 13:15.

[Erik Slagter]

De EIT files bevatten tekst in UTF-8 encoding. Een heel mooie encoding, want daarin kun je álle denkbare tekens kwijt (inclusief chinees, koreaans, japans, noem maar op). Windows leeft nog in het stenen tijdperk, die vereist dat je een encoding gebruikt die is afgestemd op je regio (Windows-1252 voor West Europa bijvoorbeeld) (terwijl daar ook een echte standaard voor is: latin-1/15, ISO8859-1/15, maar Microsoft is niet zo van de open standaarden). UTF-8 snapt Windows al helemaal niet en daarom gaat het dus fout. Zolang je e.e.a. op je ontvanger houdt, gaat het goed. Ga je omzetten naar Windows-1252, dan zal het op de ontvanger weer fout gaan.

[MiLo]

Erik, da's onzin, *Windows* ondersteunt al heel lang UTF-8 (en ook UTF-16 en nog veel meer), en heeft nog nooit enige eis gesteld aan karaktersets.

Van gebras met encoding moet je gewoon de betreffende applicatie de schuld geven.

[Erik Slagter]

Windows ondersteunt Unicode = UCS-16. Dat is heel wat anders dan UTF-8 en niemand gebruikt het (zie hierboven het bewijs). Vertel mij maar eens hoe je op een huis-tuin-en-keuken windows-installatie alles op UTF-8 zet waarbij ook alles nog gewoon blijft werken.

 

Op mijn Linux systemen werkt UTF-8 al meer dan tien jaar moeiteloos en default.

[MiLo]

Windows ondersteunt Unicode = UCS-16. Dat is heel wat anders dan UTF-8 en niemand gebruikt het (zie hierboven het bewijs). Vertel mij maar eens hoe je op een huis-tuin-en-keuken windows-installatie alles op UTF-8 zet waarbij ook alles nog gewoon blijft werken.

Er bestaat niet zoiets als "Windows op UTF-8 zetten". Elke applicatie (en elk filesysteem) mag elke karakterset gebruiken die hij maar wil.

[WanWizard]

Er daar zit 'm de crux.

 

Het onderliggende OS (de "kernel") mag het dan wellicht eventueel snappen, NIETS van wat daar bovenop draait (inclusief alle Windows componenten zoals bv CIFS / SMB / Explorer) doet er ook maar iets mee, laat staan dat je ergens iets kunt kiezen of instellen.

 

Je vertelt Windows wat je locale is, daar worden een aantal afleidingen van gemaakt, and that's it. En zelfs op onderliggend OS is het dubieus, Windows ondersteund namelijk maar een enkele ANSI codepage, waar Linux taal/locale en encoding apart behandeld. Er is een utf-8 codepage (65001), maar de multibyte ondersteuning is fundamenteel kapot (bv WriteFile() levert foute data, en dus gaat alles wat daarbovenop ligt ook fout).

[Erik Slagter]

Terwijl het op Linux gewoon werkt zonder dat je wat hoeft in te stellen (op een paar applicaties na die een string byte-voor-byte gaan parsen zonder rekening te houden met multibyte-sequences).

 

Bottom line en on topic: niet converteren naar Windows-1252, want dan werkt het op de ontvanger (Linux/UTF-8) niet meer.

[dAF2000]

Zullen we verder gaan met wat *.ap; *.cuts; *. eit; *.meta; en *. sc-files zijn?

[WanWizard]

Er staat me bij dat je samba kunt vertellen met welke codepage deze rekening moet houden. Ik heb in de E1 tijd eens uitgezocht.

Dan zorgt samba voor conversie op het moment dat je files heen- en weer sleurt tussen box en Windows systeem.

 

Heb alleen even niet paraat hoe dat ook al weer ging...

[MiLo]

ap: "access points" - versnel het "skippen" in een bestand. Als het bestand ontbreekt zijn de skip acties minder nauwkeurig, hebben meer disk IO nodig en duren langer.
sc: Zorgt voor versneld spoelen en verbetert "skippen". Als het ontbreekt is versneld spoelen niet of nauwelijks mogelijk, en ook skippen kost veel meer moeite. ap en sc bestanden kunnen opnieuw gegenereerd worden door een plugin. Als je het bronbestand (ts) hebt aangepast (geknipt ofzo) met een extern programma, verwijder dan deze bestanden en maak ze eventueel opnieuw aan.

eit: Bevat de EPG informatie van de opname, wat verschijnt als je op de info/epg toets drukt tijdens afspelen, en eventueel in de opnamelijst als het tonen ervan aan staat. Als het ontbreekt is deze info niet meer beschikbaar.

meta: Bevat de naam, opnamedatum, titel en lengte van de opname, en een aantal andere gegevens. Als het ontbreekt wordt de informatie zo goed mogelijk afgeleid uit de file en opnieuw aangemaakt.

cuts: De "knippen" in de film. Bevat start- en eindmarkeringen, en staat ook toe om secties weg te laten tijdens het afspelen. Onthoudt ook de laatstgebruikte positie om afspelen te kunnen hervatten. Als het ontbreekt onthoudt E2 nog wel de laatste 50 afspeelposities.

Het formaat van deze bestanden is publiek, maar dat wil niet zeggen dat ze voor altijd een vast formaat of betekenis hebben. Het kan zijn dat ze in de toekomst worden vervangen. De "sc" bestanden van OpenPLi bijvoorbeeld zijn nog wel compatible met het oude DMM formaat, maar bevatten veel meer informatie.

Edited by MiLo, 18 January 2015 - 19:54.

[MiLo]

Er staat me bij dat je samba kunt vertellen met welke codepage deze rekening moet houden. Ik heb in de E1 tijd eens uitgezocht.
Dan zorgt samba voor conversie op het moment dat je files heen- en weer sleurt tussen box en Windows systeem.

Dat gaat over de NAAM van de files, maar niet over de inhoud ervan.
(Ik snap wanwizards opmerking over WriteFile ook niet, die schrijft betekenisloze BYTES naar een file toe, zonder de inhoud aan te raken, en is helemaal equivalent aan de write() en aio_write() methods op Linux, die zich ook helemaal niet met character encodings bezig houden.)

En wat meer on-topic:

De EIT editor zal zich bezig houden met de inhoud van die file. Als hij de bytes in die file niet als UTF-8 interpreteert is dat gewoon een stomme fout in die applicatie die helemaal niks met het OS te maken heeft. Neem contact op met de auteur, die ongetwijfeld ook in een land woont waar accenttekens zeldzaam zijn...

[Erik Slagter]

Dit programma zal, net als 99% van alle applicaties op Windows, er van uit gaan dat de encoding Windows (1251/1252/whatever) is.

 

Net als ~10% van de content op web servers die claimen UTF-8 te zijn, maar op een Windows machine is aangemaakt en dus uiteindelijk gewoon Windows encoding is en dus mis gaat. En het ergste is nog dat IE dat herkent en het alsnog in Windows encoding laat zien, waardoor het lijkt dat andere browsers het fout doen en IE goed. Brrrr.....

 

Wat ik wil zeggen (nog maar weer een keer), NIET op een Windows installatie die filenamen of content gaan aanpassen als je het nog op een ontvanger (Linux) wilt gebruiken. Je zou hooguit de accented characters er uit kunnen halen.