search for: zewt

Hi, I offered some time ago to do some build cleanup. Today I did so and here's my slew of patches. Basically, they - touch ogg, vorbis, vorbis-tools and theora - fix a bunch of autotools issues - uniformize the use of them across the four - fix compile/link flags - use pkgconfig if it's available to detect flags - for vorbis-tools, generate and use config.h - add -uninstalled .pc stuff

Hi, I offered some time ago to do some build cleanup. Today I did so and here's my slew of patches. Basically, they - touch ogg, vorbis, vorbis-tools and theora - fix a bunch of autotools issues - uniformize the use of them across the four - fix compile/link flags - use pkgconfig if it's available to detect flags - for vorbis-tools, generate and use config.h - add -uninstalled .pc stuff

I'm not sure if this falls within the scope of tag data, somewhere else, or if there's any provision for it at all: I have a lot of songs whose native titles are in Japanese. For example, I have a song titled "螟". The filename for this song would be "02 - yume [Dream].ogg" (or even "02 - 螟 (yume) [Dream].ogg".) To automatically name this file, I'd need

...1024 frames, as expected.) ogginfo says: Warning: Vorbis stream 1 does not have headers correctly framed. Terminal header page contains additional packets or has non-zero granulepos Vendor: Xiphophorus libVorbis I 20011231 (1.0 rc3) Warning: EOS not set on stream 1 The file is available at ftp://zewt.org/local/test.ogg, if anyone wants to take a look. -- Glenn Maynard

It's difficult to programmatically determine the port dynamically assigned by -R 0. The port is output in plain (and presumably localized) text, but I've found that by far the most common use of this is for scripts. Is there currently any sane way to get this information? For the short term I'll probably just parse the plaintext "Allocated port..." message, but that's

What sort of performance is expected over GigE, with Samba 3 as the server and XP64 as the client? I havn't been able to find any current benchmarks at all. http://lists.samba.org/archive/samba/2010-June/156708.html talks about the same configuration, and suggests that the protocol should be able to break 100MB/sec. (Unfortunately, the poster disappeared without following up.) Focusing on

Background link for those unfamiliar: http://www.debian.or.jp/~kubota/unicode-symbols.html W3's suggestions for within XML: http://www.w3.org/TR/japanese-xml/ The nice thing about this document is it gives data for a bunch of different translation tables, and enumerates their differences. (This is only about Japanese encodings. I believe similar problems may exist for Chinese and Korean;

Well, my last question about this was in the middle of other stuff, but it's a basic one: why put tag info in the comment field at all? Why not use the XML field that's already there? It gives the flexibility needed to do things like translated tags easily, and keeps tag info in the same format as other data--potentially simplifying editors which read other types of metadata. The only

I've found a much better solution; it's standard (in Unicode itself), simple and more flexible: Unicode language tagging. It was made for just this purpose, in fact. A technical description is at http://www.unicode.org/unicode/reports/tr27/#tag which, like all specs, makes it sound a bit more complicated than it really is. It comes down to this: mark the language of text with U+E0001