# Mp3Tag-macOS writes malformed text field (wrong string length)

**URL:** https://community.mp3tag.de/t/mp3tag-macos-writes-malformed-text-field-wrong-string-length/59691
**Category:** Mac
**Created:** [January 13, 2023, 2:41pm UTC](https://community.mp3tag.de/t/mp3tag-macos-writes-malformed-text-field-wrong-string-length/59691 "2023-01-13T14:41:16Z")
**Posts on this page:** 1
**Showing post:** 2

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [January 16, 2023, 10:26am UTC](https://community.mp3tag.de/t/mp3tag-macos-writes-malformed-text-field-wrong-string-length/59691/2 "2023-01-16T10:26:03Z")

</div>

I think I can't add anything new to what I've written here, explaining the reasoning behind how and why Mp3tag writes a terminating null character for text fields.

> [@\[X\] Trailing nulls in ID3v2 comments](https://community.mp3tag.de/t/x-trailing-nulls-in-id3v2-comments/19227/4):
>
> OK, let me jump in there. In the past there were different reports from users that had issues with programs that were expecting all strings terminated with 00 (or 00 00 in case of UTF-16), which led to me changing the way Mp3tag writes strings in ID3v2. After reading the specification again (not sure how many times I did this), it's clear to me that it makes a implicit differentiation between "text strings" and "terminated text strings". However, at one crucial point in the ID3v2.4 spec §4 it …

Many thanks to Paul, for releasing a version of Jaikoz that reads both ways of string representation.

---

_[View the full topic](https://community.mp3tag.de/t/mp3tag-macos-writes-malformed-text-field-wrong-string-length/59691)._