Kitömörítésnél is megoldhatták volna, az lassabb maradt
A kitömörítés párhuzamosítása sokkal bonyolultabb, főleg akkor, ha úgy is mennie kell, hogy (a) a tömörítést pipe-ba végeztük, (b) a kitömörítést szintén pipe-ból végezzük, (c) a tömörített folyam tetszőelgesen nagy lehet. Ilyenkor az encoder nem tud a stream elejére a stream egészére vonatkozó információt írni (sem buffereléssel, sem random access írással), max a végére tud valamit írni, a decoder pedig csak a stream legvégén láthatja ezt az információt (ameddigre már mindenen túl kell lennie).
Ez elég jellemző probléma; többek között sem az xz, sem a pigz, sem a pbzip2 [*] nem támogatja.
[*] ha az eredeti bz2 file-t a normál bzip2 programmal hoztuk létre.
Amikor megcsináltam az lbzip2-t, akkor viszont pont ez a feature volt a lényeg, a motiváció. A stream szintjén két kritérium van: (a) a tömörített blokkoknak legyen egy méretbeli felső korlátja, (b) a tömörített blokkokat határolja el egymástól egy olyan meta-adat bitminta, amelynek előfordulási esélye a tömörített adatban (vagyis a blokkok belsejében) nagyon kicsi. Ha ez a két feltétel adott, akkor a tömörített stream-ben meghatározhatók olyan belépési pontok, amelyek között garantáltan lesz legalább egy blokkhatár, és így mind a tömörített blokkok rekonstrukciója, mind a kitömörítésük párhuzamosítható. Bővebben: https://git.sr.ht/~lersek/lbzip2-0.23-history
Ha a flac bitstream formátumra igaz a fenti két kritérium, akkor nincs elvi akadálya annak, hogy legyen hozzá párhuzamos kitömörítő.
(Az lbzip2-t a 0.23 után átvette Mikołaj Izdebski, aki a bzip2 alapformátumnak világklasszis szakértője; pl. az általa írt decoder ("yambi") a standard libbz2-nél lényegesen gyorsabb. Az általa készített és karbantartott lbzip2 2.* verzió többek között jó pár tervezési hibát is javít a 0.* sorozathoz képest; például trükkös bz2 input esetén sem igényel csillagászati mennyiségű memóriát.)