Svenska ElektronikForumet

Nej, självklart måste man ju vara rätt övertygad om att totala storleken verkligen blir mindre. Detta är ju rätt lätt att testa genom att göra ett enkelt program på PC som utför kodningen på givna filer. Sedan får man anpassa storleken på "räknarvärdet" efter hur långa sekvenserna är.

Att skilja datan från räknarvärdena behövs inte. Den ursprungliga datan behövs inte längre eftersom varannan sekvens blir 0 och varannan blir 1. Däremot _måste_ man ta hänsyn till max sekvenslängd antingen genom att ha en tillräckligt stor räknare, eller genom andra trix.

Med 3-bitars "räknarvärden" skulle en sån här dataström

000011011111000000011110000000

kunna bli såhär

100 010 001 101 111 100 111 (mellanslag enbart för läsbarhet)

Hm, så du menar att man har en *alltid* har en räknare för *all* data, även
om den bara säger "här kommer *en* etta" t.ex. Jaja, då fungerar det,
men det är väldigt stor risk att det "komprimerade" datat blir större än
originalet. Speciellt BTc datat som verkar ha många sekvenser med
varannan etta rep nolla...

Japp. Det är precis det jag menar. Det är därför det är viktigt att ha rätt så bra statistik på innehållet och ha rätt längd på "räknaren". Den här typen av kodning är väldigt vanlig.

Användes t.ex på gamla MFM-hårddiskar som då döptes om till RLL-diskar och specades för ca 1,5ggr lagringkapaciteten. Om jag inte minns helt fel så används det även i dagens diskar fast det inte syns utåt på samma sätt.

Komprimerade BMP-filer har jag också för mig kör med RLL-komprimering. Eller RLE är väl egentligen den korrekta benämningen (Run Length Encoding).