AC3/DTS bitstream decoder, for CDs in that format which have been ripped to FLAC or similarīoth of those are best served by an automatic parser which may optionally be turned off if the user wishes to convert the original data unmangled to another lossless format, or turned off if one of them somehow triggers a false positive, which shouldn't happen at all if the services are designed properly.ĪC3/DTS will be designed properly to check for 3 or more consecutive packets of compressed data, with a uniform amount of padding, assumedly signaled by the compressed format.New plugin type would be the simplest, but would prevent bundling processors that could also be force instantiated as DSPs into the same plugin as the DSP.īut in actuality, I can only think of two types of converters where this "postprocessor" service is useful: I may look into implementing this myself, but I am looking for ideas for the correct way to implement this as an API in DeaDBeeF's architecture. The DTS processor would be implemented by the same plug-in which handles the raw file formats, unless that happens to be the FFMPEG plug-in, since I think it would require different API usage to pass raw packets to its DTS decoder. This service would provide a mechanism for DTS CDs to be decoded from WAV files, or other losslessly compressed PCM formats that could contain DTS CDs. It performs a rudimentary sample rate and bit depth check first as well. If it fails to find enough data, it disables itself as well. If it finds two, it turns itself on permanently, preceding the packets with silence according to however much silence padding there was before the first DTS packet. The DTS decoder also scans the data for two consecutive DTS packets, which it validates. It also performs a sample rate and bit depth check on startup. Otherwise, it disables itself until discarded. The HDCD decoder scans up to 10 seconds of audio data for HDCD signatures, and if it finds two consecutive signatures, it turns itself on for the duration of the track. Presumably, the caller discards the block chain it passed in if it was unmodified.
Foobar dts decoder plugin code#
Both are mutually exclusive to each other, through their design, since the API tells the plug-in implementing it whether a block of sample data has been modified already by another plug-in, and the plug-in returns a status code to indicate whether it modified the sample data. The existing post processor components are for HDCD and for DTS. The decoder interface also includes a flag which may be passed in at decoder startup time, to indicate that the post processor service should not be used. The API also specifies a floating point duration in seconds that indicates how much PCM data to pre-roll into the handler, which will also be discarded by the caller.Ĭurrently, foobar2000 uses this interface from most internal and some external PCM decoding formats, such as WAV, AIFF, FLAC, WavPack, ALAC, and TAK. Only in this case, the interface is only meant to be passed decoded PCM, one block at a time, along with its format information. This is a feature request and planning ground for supporting a feature similar to foobar2000.Ī plugin API implements a central function that searches for plug-ins that handle this service, similar to decoder plug-ins.