The comments strings in vorbis are to be 8-bit clean.
info.c _v_writestring is not 8-bit clean. This leads to a malformed
comment header packet if the comment has an embedded Null:
0:0 hdr2 03 76 6F 72 62 69 73 20 00 00 00 58 69 70 68 6F .vorbis ...Xipho
16:10 70 68 6F 72 75 73 20 6C 69 62 56 6F 72 62 69 73 phorus l ibVorbis
32:20 20 49 20 32 30 30 31 30 38 31 33 01 00 00 00 65 I 20010 813....e
^^length (true)
48:30 00 00 00 54 72 61 63 6B 20 65 6E 63 6F 64 65 64 ...Track encoded
64:40 20 62 79 20 65 6E 63 6F 64 65 72 5F 65 78 61 6D by enco der_exam
80:50 70 6C 65 2E 63 0D 0A 09 09 57 69 74 68 20 61 20 ple.c... .With a
96:60 6E 75 6C 6C 2D 62 65 65 70 20 68 65 72 65 2D 2D null-bee p here--
112:70 3E 3C 01 ><.
..."\0\007>\r\n\t\t and a null-beep
there<\0\007>\r\n"...
vorbis has cut off my astounding poetry. The nerve!
It's also spitting out a malformed header, which is clearly
of secondary import here.
as you see, the actually length written is only around 0x40.,
So any subsequent headers would be unfindable when reading.
And reading might cause a sort of crashing behaviour for some folks.
The fix is trivial: use a version of _v_writestring for the 8-bit
clean input that accepts a byte-count argument. (around line 44 of info.c)
and supply the byte-count argument in _vorbis_pack_comment (around line 428)
(The vendor string uses strlen, so cannot possibly have an embedded NUL
it seems, so that bit is fine)
Note the _v_readstring (correctly, for comment headers w/ embedded NULs)
has a byte-count, and should work just fine when unpacking correctly-formed
headers (but would would bomb or give garbled poetry as it reads past the
short end-of-packet).
Of course, to add 8-bit clean data, one has to muck with vc.user_comments
directly, since no easy way to add an 8-bit-clean comment is provided
by the current API.
Anyway, either the spec or the code has to change. I hope it's the code,
so I can make my totally unworthy t-shirt claim. And yah, I realize the
comment tools don't handle the spec'ed 8-bit cleanliness yet either.
Erik.
--- >8 ----
List archives: http://www.xiph.org/archives/
Ogg project homepage: http://www.xiph.org/ogg/
To unsubscribe from this list, send a message to
'vorbis-dev-request@xiph.org'
containing only the word 'unsubscribe' in the body. No subject is
needed.
Unsubscribe messages sent to the list will be ignored/filtered.
>Of course, to add 8-bit clean data, one has to muck with vc.user_comments >directly, since no easy way to add an 8-bit-clean comment is provided >by the current API.Yes. This is deliberate - decoding is to spec, encoding limits you to 'doing sane things', unless you really know what you're doing. However, it used to not be possible to get libvorbis to create an invalid packet by doing this sort of mucking around inside the comment structure, and it still shouldn't, so this is a legit bug. I'll commit a fix soon. Thanks for the bug report. (For other people: this is a model of a good bug report. Take note! ;-)> >Anyway, either the spec or the code has to change. I hope it's the code, >so I can make my totally unworthy t-shirt claim. And yah, I realize the >comment tools don't handle the spec'ed 8-bit cleanliness yet either.Code will be fixed soon. It'll still not let you _easily_ create comments with embedded nulls in it, though. The only reason to do so is to dump chunks of binary data in there, which is strongly discouraged. UTF8 doesn't allow NULs, so 'reasonable' comments will never have them. Michael --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.