https://wiki.multimedia.cx/api.php?action=feedcontributions&user=Bumblebritches57&feedformat=atomMultimediaWiki - User contributions [en]2024-03-29T06:53:49ZUser contributionsMediaWiki 1.39.5https://wiki.multimedia.cx/index.php?title=Matroska&diff=15698Matroska2023-02-23T20:00:12Z<p>Bumblebritches57: Updated the spec url since it was dead, and added more extensions.</p>
<hr />
<div>* Extensions: mkv, mk3d, mka, mks, webm.<br />
* Website: http://matroska.org<br />
* Specification: https://matroska.org/technical/basics.html<br />
* MIME Type: <br />
** mkv: video/mkv<br />
<br />
Matroska is a free, general-purpose container format designed to supplant currently existing container formats like [[AVI]]. The shortcomings in the Matroska design sparked the development of [[NUT]].<br />
<br />
==Codec IDs==<br />
<br />
An incomplete list of Matroska codec IDs can be found here: http://www.matroska.org/technical/specs/codecid/index.html<br />
<br>Haali media splitter has another list here: http://haali.cs.msu.ru/mkv/codecs.pdf<br />
<br />
The following Codec IDs are known to be in use:<br />
<br />
*V_DIRAC: [[Dirac]] [http://diracvideo.org/wiki/DiracInMatroska]<br />
*V_MS/VFW/FOURCC: VfW compatibility mode<br />
*V_MPEG1: [[MPEG-1]]<br />
*V_MPEG2: [[MPEG-2]]<br />
*V_MPEG4/ISO/SP: [[MPEG-4]] part 2 Simple Profile (divx4)<br />
*V_MPEG4/ISO/ASP: [[MPEG-4]] part 2 Advanced Simple Profile<br />
*V_MPEG4/ISO/AP: MPEG-4 part 10 Advanced Profile ([[H.264]])<br />
*V_MPEG4/MS/V3: Divx3<br />
*V_REAL/RV10: [[RealVideo]] 1<br />
*V_REAL/RV20: [[RealVideo G2]]<br />
*V_REAL/RV30: [[RealVideo 3]]<br />
*V_REAL/RV40: [[RealVideo 4]]<br />
*V_SNOW: FFmpeg [[Snow]]<br />
*V_THEORA: Xiph [[Theora]]<br />
*V_QUICKTIME: Quicktime compatiblity mode (mainly for [[SVQ3]])<br />
*V_UNCOMPRESSED: Uncompressed, format defined by KaxCodecColourSpace<br />
*V_VC1: Deprecated; Use V_MS/VFW/FOURCC with [[WMV3]] or [[WVC1]] instead [https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-August/034825.html]<br />
*V_VP8: VP8 [http://www.webmproject.org/]<br />
;<br />
*A_AAC: [[Advanced Audio Coding]]<br />
*A_AAC/MPEGx/y: Obsolete; Use A_AAC instead<br />
*A_AC3: [[A52|ATSC A/52a]]<br />
*A_EAC3: [[A52|ATSC A/52b]] [http://lists.matroska.org/pipermail/matroska-devel/2007-April/003174.html]<br />
*A_DTS: [[DTS|DTS Coherent Acoustics]]<br />
*A_FLAC: [[FLAC]]<br />
*A_MPC: [[Musepack]] SV8<br />
*A_MPEG/L1: [[MP1]]<br />
*A_MPEG/L2: [[MP2]]<br />
*A_MPEG/L3: [[MP3]]<br />
*A_PCM/INT/BIG: Uncompressed PCM, Big-Endian<br />
*A_PCM/INT/LIT: Uncompressed PCM, Little-Endian<br />
*A_PCM/FLOAT/IEEE: Uncompressed PCM, IEEE floating-point<br />
*A_REAL/14_4: [[VSELP]]<br />
*A_REAL/28_8: [[RealAudio 28.8]]<br />
*A_REAL/ATRC: [[Sony ATRAC|ATRAC3]], using Real extradata and xor format ([[RealAudio atrc]])<br />
*A_REAL/COOK: [[RealAudio cook]]<br />
*A_REAL/SIPR: [[RealAudio sipr]]<br />
*A_TTA1: [[TTA|True Audio lossless]]<br />
*A_VORBIS: [[Vorbis]]<br />
*A_WAVPACK4: [[WavPack]]<br />
*A_QUICKTIME: Quicktime compatibility (uncommon)<br />
*A_MS/ACM: Windows ACM compatibility (uncommon)<br />
<br />
;Proposed but not yet implemented:<br />
<br />
*A_SPEEX: [[Speex]] [http://wiki.xiph.org/index.php/Oggless]<br />
<br />
[[Category: Container Formats]]</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=User:Bumblebritches57&diff=15503User:Bumblebritches572020-08-17T00:32:40Z<p>Bumblebritches57: </p>
<hr />
<div>I'm the creator of [https://github.com/MarcusJohnson91/FoundationIO FoundationIO], [https://github.com/MarcusJohnson91/OVIA OVIA], and several other, less useful libraries.</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=Talk:Portable_Network_Graphics&diff=15410Talk:Portable Network Graphics2018-12-10T12:18:39Z<p>Bumblebritches57: </p>
<hr />
<div>How exactly does interlacing work?<br />
<br />
Are scanlines created from the 8x8 map?<br />
<br />
Wikipedia claims that the 7th layer encodes the entire image, but in my tests, that can't be true, so how does that work?<br />
<br />
how do the levels combine together?<br />
<br />
<br />
Edit:<br />
<br />
I've since learned that the adam7 interlacing scheme works on 8x8 blocks repeated over the picture as much as nessicary.<br />
<br />
so in a 24x8 image, you'd loop over the left most 8 pixels (0-7) for the first adam7 block, then loop over the second block from pixels 8-15, and the third would be 16-23</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=User:Bumblebritches57&diff=15409User:Bumblebritches572018-12-10T12:15:16Z<p>Bumblebritches57: </p>
<hr />
<div>I'm the creator of [https://github.com/bumblebritches57/FoundationIO FoundationIO], [https://github.com/bumblebritches57/OVIA OVIA], and several other, less useful libraries.</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=Audio_Interchange_File_Format&diff=15375Audio Interchange File Format2018-08-13T23:33:35Z<p>Bumblebritches57: /* Sample Rate */</p>
<hr />
<div>* Extensions: aif, aiff<br />
* Company: [[Apple]]<br />
* Official Specification: http://multimedia.cx/mirror/AudioIFF1_2_1.htm<br />
* MIME Types:<br />
** aif, aiff: audio/aiff, audio/x-aiff, or audio/x-pn-aiff<br />
* Samples: http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Samples.html<br />
<br />
AIFF files exclusively store audio data. They serve as somewhat of an Apple analog of the [[Microsoft Wave]] format.<br />
<br />
Comprehensive AIFF tag listing: http://hul.harvard.edu/jhove/aiff-hul.html<br />
<br />
== Sample Rate ==<br />
The sample rate is stored as an extended precision float (80 bits, 10 bytes)<br />
<br />
{| class="wikitable"<br />
|+ SampleRate Layout <br />
|-*<br />
! scope="col" | Type<br />
! scope="col" | Size<br />
|-<br />
| SignBit || 1 bit.<br />
|-<br />
| Exponent || 15 bits.<br />
|-<br />
| Mantissa || 64 bits.<br />
|}<br />
<br />
{| class="wikitable"<br />
|+ Example Sample Rates <br />
|-*<br />
! scope="col" | Value<br />
! scope="col" | Bitset<br />
|-<br />
| 8000 || 0x400BFA00000000000000<br />
|-<br />
| 44100 || 0x400EAC44000000000000<br />
|-<br />
| 48000 || 0x400EBB80000000000000<br />
|-<br />
| 88200 || 0x400FAC44000000000000<br />
|-<br />
| 96000 || 0x400FBB80000000000000<br />
|-<br />
| 192000 || 0x4010BB80000000000000<br />
|}<br />
<br />
[[Category:Container Formats]]</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=Audio_Interchange_File_Format&diff=15374Audio Interchange File Format2018-08-13T23:30:11Z<p>Bumblebritches57: Described the sample rate format a bit</p>
<hr />
<div>* Extensions: aif, aiff<br />
* Company: [[Apple]]<br />
* Official Specification: http://multimedia.cx/mirror/AudioIFF1_2_1.htm<br />
* MIME Types:<br />
** aif, aiff: audio/aiff, audio/x-aiff, or audio/x-pn-aiff<br />
* Samples: http://www-mmsp.ece.mcgill.ca/Documents/AudioFormats/AIFF/Samples.html<br />
<br />
AIFF files exclusively store audio data. They serve as somewhat of an Apple analog of the [[Microsoft Wave]] format.<br />
<br />
Comprehensive AIFF tag listing: http://hul.harvard.edu/jhove/aiff-hul.html<br />
<br />
== Sample Rate ==<br />
The sample rate is stored as an extended precision float (80 bits, 10 bytes)<br />
<br />
{| class="wikitable"<br />
|+ SampleRate Layout <br />
|-*<br />
! scope="col" | Type<br />
! scope="col" | Size<br />
|-<br />
| SignBit || 1 bit.<br />
|-<br />
| Exponent || 15 bits.<br />
|-<br />
| Mantissa || 64 bits.<br />
|}<br />
<br />
{| class="wikitable"<br />
|+ Example Sample Rates <br />
|-*<br />
! scope="col" | Value<br />
! scope="col" | Bitset<br />
|-<br />
| 44100 || 0x400EAC44000000000000<br />
|-<br />
| 48000 || 0x400EBB80000000000000<br />
|-<br />
| 88200 || 0x400FAC44000000000000<br />
|-<br />
| 96000 || 0x400FBB80000000000000<br />
|-<br />
| 192000 || 0x4010BB80000000000000<br />
|}<br />
<br />
[[Category:Container Formats]]</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=User:Bumblebritches57&diff=15354User:Bumblebritches572018-03-03T17:43:16Z<p>Bumblebritches57: </p>
<hr />
<div>I'm the creator of [https://github.com/bumblebritches57/FoundationIO FoundationIO], [https://github.com/bumblebritches57/libPCM libPCM], [https://github.com/bumblebritches57/ModernPNG ModernPNG], and several other, less useful libraries.</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=Meridian_Lossless_Packing&diff=15310Meridian Lossless Packing2017-10-27T08:29:38Z<p>Bumblebritches57: </p>
<hr />
<div>* Whitepaper: http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF ([[Mirrored Files|mirrored]])<br />
* Samples: http://samples.mplayerhq.hu/A-codecs/lossless/mlp/<br />
<br />
Also known as Dolby [[TrueHD]]. This is a lossless audio codec for DVD audio, as stated in the whitepaper, it uses IIR prediction (like TrueAudio or Monkey's Audio) and [[Golomb]] codes residue packing.<br />
<br />
You can download samples created by [[User:Rjamorim|rjamorim]] at RareWares:<br />
* http://www.rarewares.org/rja/samples/<br />
they were created with Surcode MLP, and the original samples are also available ([[WavPack]]-encoded). God Save The Queen is a 6ch/96k/24b sample from Queen's A Night At The Opera DVD-A. luckynight is the same sample used [http://samples.mplayerhq.hu/A-codecs/lossless/ elsewhere] in this wiki, and 440hz is, as the name implies, a simple 440 Hz tone.<br />
<br />
You can [http://www.rarewares.org/ contact] rjamorim if you want other samples encoded.<br />
<br />
<br />
== Overview ==<br />
<br />
A good overview of the encoding/decoding process is available on Meridian's website:<br />
* http://www.meridian-audio.com/w_paper/mlp_jap_new.PDF<br />
<br />
An MLP audio stream can contain multiple substreams - a decoder can optionally decode only a subset of these substreams. Typically stereo files are encoded with a single substream, while surround files have one substream containing a stereo downmix, and another substream containing the additional surround channels and matrixing parameters to extract the front channels from the stereo downmix.<br />
<br />
MLP streams can specify that the second substream can have a lower bit depth or sampling frequency than the first substream. TrueHD removes this capability.<br />
<br />
== Stream structure ==<br />
<br />
A stream is split up into a number of small blocks, or "access units". Each access unit contains coded data for 40 (44100/48000Hz), 80 (88200/96000Hz) or 160 (176400/192000Hz) samples. Periodically an access unit contains a "major sync" header that contains stream metadata (analogous to a sequence header in a video codec).<br />
<br />
All values in the stream are big endian.<br />
<br />
=== Access unit structure ===<br />
<br />
Each access unit starts with a parity nibble (details later), and then a 12-bit length field (in units of two bytes). Following this is a 2-byte value that looks like it may be some form of DTS - in most cases each packet will have a value that is the sum of the previous packet's value and the number of samples per packet, but some values can diverge from this.<br />
<br />
After these first four bytes, the major sync header can optionally appear - if the next four bits are all one, then the following 28 bytes (including the four one bits) are a major sync header.<br />
<br />
Following this is an index of two- or four-byte entries for each substream. These have the following format:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Size !! Meaning<br />
|-<br />
| 1 bit || If set, indicates an extra 16 bits of data are present<br />
|-<br />
| 1 bit || If clear, indicates that the substream data starts with a "restart header"<br />
|-<br />
| 1 bit || If set, indicates that the substream data contains extra parity information<br />
|-<br />
| 1 bit || Unknown <br />
|-<br />
| 12 bits || Offset, in units of two bytes, of the end of the data for this substream from the start of the start of the substream data block (ie length of this substream's data plus all previous)<br />
|-<br />
| 16 bits || (Optional, present if first bit was set) Unknown<br />
|-<br />
|}<br />
<br />
Following these entries is the data for each substream.<br />
<br />
The first nibble of the access unit is a parity check on the access unit header - XOR'ing together the nibbles of the first four bytes and the substream entry table above (excluding the major sync header if present and the substream data) should give a result of 0xF.<br />
<br />
=== Major sync header ===<br />
<br />
The major sync header is 28 bytes long, and starts with the three bytes F8 72 6F, followed by BB for MLP streams, or BA for TrueHD streams. This contains details like the number of substreams, the channel arrangement, bit depth and sampling frequency. In MLP streams major syncs must occur between every 8 and 32 access units. In TrueHD streams spacings of 128 access units have been observed.<br />
<br />
The major sync header for MLP streams has the following format:<br />
<br />
{| class="wikitable"<br />
|-<br />
! Size !! Meaning<br />
|-<br />
| 24 bits || SYNC_MAJOR (0xf8726f) <br />
|-<br />
| 8 bits || SYNC_MLP (0xbb) <br />
|-<br />
| 4 bits || Bit-depth (substream 0)<br />
|-<br />
| 4 bits || Bit-depth (substream 1)<br />
|-<br />
| 4 bits || Sample-rate (substream 0)<br />
|-<br />
| 4 bits || Sample-rate (substream 1)<br />
|-<br />
| 11 bits || Unknown<br />
|-<br />
| 5 bits || Channel arrangement <br />
|-<br />
| 16 bits || MAJOR_SYNC_INFO_SIGNATURE (0xb752)<br />
|-<br />
| 16 bits || Info flags <br />
|-<br />
| 16 bits || Unknown<br />
|-<br />
| 1 bit || Set to 1 if VBR<br />
|-<br />
| 15 bits || Coded peak bitrate<br />
|-<br />
| 4 bits || Number of substreams<br />
|-<br />
| 4 bits || Unknown (set to 0x1)<br />
|-<br />
| 8 bits || Substream info <br />
|-<br />
| 5 bits || Unknown (some substream info) <br />
|-<br />
| 5 bits || Sample wordlength (no. of bits)<br />
|-<br />
| 6 bits || Channel occupancy <br />
|-<br />
| 3 bits || Unknown<br />
|-<br />
| 10 bits || Speaker layout?<br />
|-<br />
| 3 bits || Copy protection<br />
|-<br />
| 16 bits || Unknown (set to 0x8080)<br />
|-<br />
| 7 bits || Unknown<br />
|-<br />
| 4 bits || Source format<br />
|-<br />
| 5 bits || Summary info<br />
|-<br />
|}<br />
<br />
=== Substream data block ===<br />
<br />
A substream data block contains one or more chunks of data. <br />
<br />
A data chunk may start with a restart header followed by a decoding parameter block, just a decoding parameter block, or may just go straight into data.<br />
<br />
A decoding parameter block is present if the first bit is '1'. If the next bit is also '1', a restart header is also present, before the decoding parameter block.<br />
<br />
The encoded residual data then follows. If data_check_present was set in the last restart header for this substream, the data is preceded by a 16-bit count indicating how many bits of data should be present, and followed by an 8-bit value (currently unknown, maybe a CRC). The bit count includes the 16 count bits, but not the 8 extra bits.<br />
<br />
A single bit marks the end of a chunk - this is set to 1 if it is the last chunk in the data block.<br />
<br />
After the last chunk, padding bits are inserted to align the bitstream to a 16-bit boundary. The 32-bit value D2 34 D2 34 may then optionally be present, which indicates that this was the last access unit of the audio stream.<br />
<br />
If substream parity information was indicated in the substream index earlier, the data for the substream is terminated by a parity check byte and a CRC byte. The parity check is such that XORing all the bytes of the substream up to (and including) the parity byte should give the value 0xA9.<br />
<br />
=== Restart header ===<br />
<br />
The restart header contains information necessary for the decoding of the audio stream. It is generally present in packets containing a major sync header. The restart header starts with a 14-bit code, either 0x31EA or 0x31EB. MLP streams only use 0x31EA headers, TrueHD streams use either/both. The difference lies mostly in the way rematrixing is done.<br />
<br />
TODO: Document more<br />
<br />
[[Category:Audio Codecs]]<br />
[[Category:Lossless Audio Codecs]]<br />
[[Category: Multichannel Audio Codecs]]<br />
<br />
=== Weirdness ===<br />
It appears that the sample rate field is a full byte, with each sample rate being encoded in chunks of 16, so 0-15 = 48000, 16-31 = 96000, 32-47 = 192000, then there's a hole from 48-127, followed by 128-143 = 44100, 144-159 = 88200, 160-175 = 176400, then a second hole from 176-255</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=Talk:Portable_Network_Graphics&diff=15288Talk:Portable Network Graphics2017-10-05T13:46:33Z<p>Bumblebritches57: Created page with "How exactly does interlacing work? Are scanlines created from the 8x8 map? Wikipedia claims that the 7th layer encodes the entire image, but in my tests, that can't be true,..."</p>
<hr />
<div>How exactly does interlacing work?<br />
<br />
Are scanlines created from the 8x8 map?<br />
<br />
Wikipedia claims that the 7th layer encodes the entire image, but in my tests, that can't be true, so how does that work?<br />
<br />
how do the levels combine together?</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=Sony_Wave64&diff=15287Sony Wave642017-09-26T08:51:14Z<p>Bumblebritches57: </p>
<hr />
<div>*Extension: w64<br />
*Company: Sony<br />
*Specification: http://www.vcs.de/fileadmin/user_upload/MBS/PDF/Whitepaper/Informations_about_Sony_Wave64.pdf<br />
<br />
Sony Wave64 (.w64) is a general audio container format.<br />
<br />
Wave64 is an extension to [[Microsoft_Wave|WAV]] to support a basically limitless amount of samples, channels, bit depths, etc.<br />
<br />
Like all other RIFF based formats, if a chunk's payload size is not even, it is padded by 1 byte to make it so.<br />
<br />
it's chunk format is very similar to Wave's, except it's chunks are all lower case, and have been extended to 128 bits, with 96 bits of identifiable junk in order to be a GUID.<br />
<br />
The ChunkSize field includes the size of the marker and it's own size as well.<br />
<br />
{| class="wikitable"<br />
|+ Chunk Layout <br />
|-*<br />
! scope="col" | Type<br />
! scope="col" | Size<br />
|-<br />
| ChunkGUID || 128 bits.<br />
|-<br />
| ChunkSize || 64 bits.<br />
|-<br />
| ChunkPayload || ChunkSize in bytes.<br />
|}<br />
<br />
{| class="wikitable"<br />
|+ Known Chunk GUIDs<br />
|-*<br />
! scope="col" | Name<br />
! scope="col" | GUID<br />
|-<br />
| RIFF || 66666972-912E-11CF-A5D6-28DB04C10000<br />
|-<br />
| LIST || 7473696C-912F-11CF-A5D6-28DB04C10000<br />
|-<br />
| WAVE || 65766177-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| FMT || 20746D66-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| FACT || 74636166-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| DATA || 61746164-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| LEVL || 6C76656C-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| JUNK || 6b6E756A-ACF3-11D3-8CD1-00C04f8EDB8A<br />
|-<br />
| BEXT || 74786562-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| MARKER || ABF76256-392D-11D2-86C7-00C04F8EDB8A<br />
|-<br />
| SUMMARY LIST || 925F94BC-525A-11D2-86DC-00C04F8EDB8A<br />
|}<br />
<br />
[[Category:Container Formats]]</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=Sony_Wave64&diff=15286Sony Wave642017-09-26T08:46:55Z<p>Bumblebritches57: Added some details, and a few tables to help explain the W64 format.</p>
<hr />
<div>*Extension: w64<br />
*Company: Sony<br />
*Specification: http://www.vcs.de/fileadmin/user_upload/MBS/PDF/Whitepaper/Informations_about_Sony_Wave64.pdf<br />
<br />
Sony Wave64 (.w64) is a general audio container format.<br />
<br />
Wave64 is an extension to [[Microsoft_Wave|WAV]] to support a basically limitless amount of samples, channels, bit depths, etc.<br />
<br />
Like all other RIFF based formats, if a chunk's payload size is not even, it is padded by 1 byte to make it so.<br />
<br />
it's chunk format is very similar to Wave's, except it's chunks are all lower case, and have been extended to 128 bits, with 96 bits of identifiable junk in order to be a GUID.<br />
<br />
{| class="wikitable"<br />
|+ Chunk Layout <br />
|-*<br />
! scope="col" | Type<br />
! scope="col" | Size<br />
|-<br />
| ChunkGUID || 128 bits.<br />
|-<br />
| ChunkSize || 64 bits.<br />
|-<br />
| ChunkPayload || ChunkSize in bytes.<br />
|}<br />
<br />
{| class="wikitable"<br />
|+ Known Chunk GUIDs<br />
|-*<br />
! scope="col" | Name<br />
! scope="col" | GUID<br />
|-<br />
| RIFF || 66666972-912E-11CF-A5D6-28DB04C10000<br />
|-<br />
| LIST || 7473696C-912F-11CF-A5D6-28DB04C10000<br />
|-<br />
| WAVE || 65766177-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| FMT || 20746D66-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| FACT || 74636166-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| DATA || 61746164-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| LEVL || 6C76656C-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| JUNK || 6b6E756A-ACF3-11D3-8CD1-00C04f8EDB8A<br />
|-<br />
| BEXT || 74786562-ACF3-11D3-8CD1-00C04F8EDB8A<br />
|-<br />
| MARKER || ABF76256-392D-11D2-86C7-00C04F8EDB8A<br />
|-<br />
| SUMMARY LIST || 925F94BC-525A-11D2-86DC-00C04F8EDB8A<br />
|}<br />
<br />
[[Category:Container Formats]]</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=User:Bumblebritches57&diff=15285User:Bumblebritches572017-09-26T08:10:17Z<p>Bumblebritches57: Created my page with a few links to some of the libraries I've made</p>
<hr />
<div>I'm the creator of [https://github.com/bumblebritches57/BitIO BitIO], [https://github.com/bumblebritches57/ModernPNG ModernPNG], and several other, less useful libraries.</div>Bumblebritches57https://wiki.multimedia.cx/index.php?title=Talk:Sony_Wave64&diff=15284Talk:Sony Wave642017-09-26T08:00:16Z<p>Bumblebritches57: Created page with "The link is dead."</p>
<hr />
<div>The link is dead.</div>Bumblebritches57