11
Lossless / Other Codecs / Re: libttaR (TTA rewrite part 2)
Last post by rdtsh -smaller packets, wouldn't TTA be fixed at about a second - that's not small?yes, with CD quality audio, the framesize is 180KiB.
smaller packets, wouldn't TTA be fixed at about a second - that's not small?yes, with CD quality audio, the framesize is 180KiB.
the tta wikipedia page was deletedBeen flagged as looking like an ad for twelve years ... and not too wrongfully either.
I have never considered the idea of compressing according to the content by giving the right to play with block sizes.
Of course, for LossyWav, this may be necessary by nature.To achieve the best reduction, i.e. where bits to remove changes within a larger block size, it is indeed necessary.
The only problem for me right now is the processing speed of LossyWav.While it is readily acknowledged that lossyWAV is not particularly fast, it is what it is - and as each file need only be processed once, it's not the worst downside, IMO.
Using (old version) ffmpeg of cli tool for performance comparison is flawed and extremely biased.The tta codec version should be the same between the version I used and the current version, or at least the differences are negligible. You are always welcome to post your own benchmarks.
Also current ffmpeg cli tool have bad performance with smaller packets due to clumsy MT work of ex-developer.ok
Also just to run generic build of ffmpeg for the first time takes extra timeThat cannot be more than a millisecond.
Also this repo does not have any SIMD x86 assembly and the only way performance can go up if compiler is modern clang.If anything, that is a virtue.