<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Releases on ebyte.org</title>
    <link>https://ebyte.org/tags/releases/</link>
    <description>Recent content in Releases on ebyte.org</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 20 Oct 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://ebyte.org/tags/releases/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>EByte Case Study Reading Every Chunk of a WAV File</title>
      <link>https://ebyte.org/ebyte-case-study-reading-every-chunk-of-a-wav-file/</link>
      <pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ebyte.org/ebyte-case-study-reading-every-chunk-of-a-wav-file/</guid>
      <description>&lt;p&gt;The &lt;a href=&#34;https://ebyte.org/ebyte-case-study-reading-and-editing-a-real-wav-file/&#34;&gt;first WAV case study&lt;/a&gt; used a schema that knew exactly three chunks in a fixed order. Real WAV files aren&amp;rsquo;t that tidy. Recorders and editors add a &lt;code&gt;LIST&lt;/code&gt; chunk with a title and the software name, and some put it before the audio, some after. EByte 0.2.0 adds a &lt;code&gt;repeat&lt;/code&gt; field for this, and this case study tries it on a WAV file with metadata, using the released &lt;code&gt;ebyte&lt;/code&gt; 0.2.0 Linux binary downloaded from GitHub. Its checksum matched SHA256SUMS before anything ran.&lt;/p&gt;</description>
    </item>
    <item>
      <title>EByte Launches One Schema for Reading and Writing Binary Files</title>
      <link>https://ebyte.org/ebyte-launches-one-schema-for-reading-and-writing-binary-files/</link>
      <pubDate>Tue, 20 Oct 2026 00:00:00 +0000</pubDate>
      <guid>https://ebyte.org/ebyte-launches-one-schema-for-reading-and-writing-binary-files/</guid>
      <description>&lt;p&gt;EByte 0.1 is out. It&amp;rsquo;s a small Go library and a command-line tool for binary file formats, and it does one thing that sounds obvious until you&amp;rsquo;ve tried it: you describe a format once, and that single description reads files, writes them and explains them.&lt;/p&gt;&#xA;&lt;p&gt;Here&amp;rsquo;s the usual situation it&amp;rsquo;s meant for. A device exports a file, or an old program saves one, and you need to look inside it, change a value and save it again. You end up writing a reader. Then a writer, which has to agree with the reader to the byte. Then, when a file won&amp;rsquo;t load, you open a hex editor and count bytes by hand to find out which field went wrong. That&amp;rsquo;s three descriptions of the same format, and they drift.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
