xine-devel — internal xine developers' list

[xine-devel] Dynamic volume adjustment in xine

[Jan S. <jan...@ma...>]

Hi Torsten!

Some two years ago I emailed you about changes made to xine post version 1.2.10 and how they 
affect Amarok 1.4 and Kaffeine distributed with TDE (successor of KDE3). The email thread was 
called "Problems with logarithmic volume scaling", started in late June 2023. I admit that back 
then I completely dropped the ball on this. Now I want to go back to one of the topics I raised 
in 2023, namely automatic volume adjustment during playback. Back then you wrote:

> When using xinue --verbose=2, you will get the explaination in the log,
> something like "Source too loud, adding -2.5dB declip filter.".
> For some technical background, see the comment in
> xine-lib-1.2/src/audio_dec/xine_mad_decoder.c, starting with
> "Report peak level _before_ clipping".
> The issue can (and should) be avoided by encoding mp3 with
> lame --scale=0.707 beforehand.

Would it be possible to add a runtime configuration option that makes this volume adjustment an 
opt-out behaviour? At the moment, the user experience is noticeably degraded because of this, 
because the volume lowers unexpectedly during playback. I don't think it is realistic to tell the 
users to re-encode their music collections with some specific `lame` settings. In my collection I 
estimate that around 80-90% of tracks are affected, and I know they play without issues on other 
players (vlc, mpv, standalone mp3 player). If this behaviour could be toggled on and off, we can 
than expose it via configuration to the users and let them decide whether they want this enabled 
or not.

Best regards,
Janek

Re: [xine-devel] xine-ui: some utf-8 conversions

[Xavier B. <xa...@ba...>]

Le 2025-03-07 19:53, Xavier Bachelot a écrit :
> Hi Torsten,
> 
> Some stuff is still utf8-encoded in xine-ui, maybe the attached patches 
> could helpful ?
> 
> Regards,
> Xavier

Re-sending with compressed patch, the previous mail was ended up in the 
moderation queue.

Regards,
Xavier

Re: [xine-devel] xine-lib build error on i686

[Xavier B. <xa...@ba...>]

Le 2025-02-08 00:00, Xavier Bachelot via xine-devel a écrit :
> Hi Torsten,
> 
> I'm not sure how much 32 bits is really useful these days, but I get 
> this when building on i686:
> 
> wine/win32.c: In function 'expEnumDisplayMonitors':
> wine/win32.c:2524:12: error: too many arguments to function 
> 'callback_proc'; expected 0, have 4
>  2524 |     return callback_proc(0, dc, r, callback_param);
>       |            ^~~~~~~~~~~~~ ~
> wine/win32.c: In function 'expEnumWindows':
> wine/win32.c:2624:9: error: too many arguments to function 
> 'callback_func'; expected 0, have 2
>  2624 |     i = callback_func(0, callback_param);
>       |         ^~~~~~~~~~~~~ ~
> wine/win32.c:2625:10: error: too many arguments to function 
> 'callback_func'; expected 0, have 2
>  2625 |     i2 = callback_func(1, callback_param);
>       |          ^~~~~~~~~~~~~ ~
> wine/win32.c: In function 'expCreateFileA':
> wine/win32.c:3512:9: warning: ignoring return value of 'asprintf' 
> declared with attribute 'warn_unused_result' [-Wunused-result]
>  3512 |         asprintf(&tmp,"%s/%s",win32_def_path,x?(x+1):cs1);
>       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> make[2]: *** [Makefile:1228: wine/libwine_la-win32.lo] Error 1
> 
> Full log here:
> https://kojipkgs.fedoraproject.org//work/tasks/9937/128959937/build.log
> 
> Regards,
> Xavier
> 

Hi Torsten,

I can confirm 
https://sourceforge.net/p/xine/xine-lib-1.2/ci/5a68e8b08fd5378780f76c3ab957d790209388db/ 
fixes win32dll build with gcc15.

Regards,
Xavier

[xine-devel] xine-lib build error on i686

[Xavier B. <xa...@ba...>]

Hi Torsten,

I'm not sure how much 32 bits is really useful these days, but I get 
this when building on i686:

wine/win32.c: In function 'expEnumDisplayMonitors':
wine/win32.c:2524:12: error: too many arguments to function 
'callback_proc'; expected 0, have 4
  2524 |     return callback_proc(0, dc, r, callback_param);
       |            ^~~~~~~~~~~~~ ~
wine/win32.c: In function 'expEnumWindows':
wine/win32.c:2624:9: error: too many arguments to function 
'callback_func'; expected 0, have 2
  2624 |     i = callback_func(0, callback_param);
       |         ^~~~~~~~~~~~~ ~
wine/win32.c:2625:10: error: too many arguments to function 
'callback_func'; expected 0, have 2
  2625 |     i2 = callback_func(1, callback_param);
       |          ^~~~~~~~~~~~~ ~
wine/win32.c: In function 'expCreateFileA':
wine/win32.c:3512:9: warning: ignoring return value of 'asprintf' 
declared with attribute 'warn_unused_result' [-Wunused-result]
  3512 |         asprintf(&tmp,"%s/%s",win32_def_path,x?(x+1):cs1);
       |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [Makefile:1228: wine/libwine_la-win32.lo] Error 1

Full log here:
https://kojipkgs.fedoraproject.org//work/tasks/9937/128959937/build.log

Regards,
Xavier

[xine-devel] xine-ui: fix make dist

[Xavier B. <xa...@ba...>]

Hi,

src/xitk/splash.c was removed in 3bd1de, but po/POTFILES.in was not 
modified accordingly.
This breaks make dist.
Here's a patch to fix this.

Regards,
Xavier

[xine-devel] xine-ui build failure with gcc 15

[Xavier B. <xa...@ba...>]

Hi,

xine-ui 0.99.14 fails to build with gcc 15:

"""
In file included from /usr/include/bits/getopt_posix.h:27,
                  from /usr/include/unistd.h:903,
                  from main.h:28,
                  from options.c:34:
/usr/include/bits/getopt_core.h:91:12: error: conflicting types for 
‘getopt’; have ‘int(int,  char * const*, const char *)’
    91 | extern int getopt (int ___argc, char *const *___argv, const char 
*__shortopts)
       |            ^~~~~~
In file included from options.c:29:
../../src/common/getopt.h:136:12: note: previous declaration of ‘getopt’ 
with type ‘int(void)’
   136 | extern int getopt ();
       |            ^~~~~~
make[3]: *** [Makefile:501: options.o] Error 1
"""

Full build log :
https://kojipkgs.fedoraproject.org//work/tasks/3966/128163966/build.log

Regards,
Xavier

[xine-devel] xine-lib build failure with gcc 15

[Xavier B. <xa...@ba...>]

Hi,

A current snapshot of xine-lib (20241217 - 15302) fails to build with 
gcc 15.

Here's the excerpt of the log:

"""
In file included from builtins.c:41:
../input/input_file.c: In function 'file_input_class_get_dir':
../input/input_file.c:738:43: error: initialization of 'int (*)(void)' 
from incompatible pointer type 'int (*)(const xine_mrl_t *, const 
xine_mrl_t *)' {aka 'int (*)(const struct xine_mrl_s *, const struct 
xine_mrl_s *)'} [-Wincompatible-pointer-types]
   738 |   int                 (*func) ()        = 
file_input_sortfiles_default;
       |                                           
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../input/input_file.c:654:12: note: 'file_input_sortfiles_default' 
declared here
   654 | static int file_input_sortfiles_default (const xine_mrl_t *s1, 
const xine_mrl_t *s2) {
       |            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../input/input_file.c:918:59: error: passing argument 4 of 'qsort' from 
incompatible pointer type [-Wincompatible-pointer-types]
   918 |       qsort(dir_files, num_dir_files, sizeof(xine_mrl_t), func);
       |                                                           ^~~~
       |                                                           |
       |                                                           int 
(*)(void)
In file included from ../../include/xine/xineutils.h:27,
                  from ../../include/xine/input_plugin.h:28,
                  from ../../include/xine/xine_internal.h:35,
                  from builtins.h:26,
                  from builtins.c:29:
/usr/include/stdlib.h:971:34: note: expected '__compar_fn_t' {aka 'int 
(*)(const void *, const void *)'} but argument is of type 'int 
(*)(void)'
   971 |                    __compar_fn_t __compar) __nonnull ((1, 4));
       |                    ~~~~~~~~~~~~~~^~~~~~~~
/usr/include/stdlib.h:948:15: note: '__compar_fn_t' declared here
   948 | typedef int (*__compar_fn_t) (const void *, const void *);
       |               ^~~~~~~~~~~~~
../input/input_file.c:921:61: error: passing argument 4 of 'qsort' from 
incompatible pointer type [-Wincompatible-pointer-types]
   921 |       qsort(hide_files, num_hide_files, sizeof(xine_mrl_t), 
func);
       |                                                             ^~~~
       |                                                             |
       |                                                             int 
(*)(void)
/usr/include/stdlib.h:971:34: note: expected '__compar_fn_t' {aka 'int 
(*)(const void *, const void *)'} but argument is of type 'int 
(*)(void)'
   971 |                    __compar_fn_t __compar) __nonnull ((1, 4));
       |                    ~~~~~~~~~~~~~~^~~~~~~~
/usr/include/stdlib.h:948:15: note: '__compar_fn_t' declared here
   948 | typedef int (*__compar_fn_t) (const void *, const void *);
       |               ^~~~~~~~~~~~~
../input/input_file.c:924:61: error: passing argument 4 of 'qsort' from 
incompatible pointer type [-Wincompatible-pointer-types]
   924 |       qsort(norm_files, num_norm_files, sizeof(xine_mrl_t), 
func);
       |                                                             ^~~~
       |                                                             |
       |                                                             int 
(*)(void)
/usr/include/stdlib.h:971:34: note: expected '__compar_fn_t' {aka 'int 
(*)(const void *, const void *)'} but argument is of type 'int 
(*)(void)'
   971 |                    __compar_fn_t __compar) __nonnull ((1, 4));
       |                    ~~~~~~~~~~~~~~^~~~~~~~
/usr/include/stdlib.h:948:15: note: '__compar_fn_t' declared here
   948 | typedef int (*__compar_fn_t) (const void *, const void *);
       |               ^~~~~~~~~~~~~
make[3]: *** [Makefile:832: builtins.lo] Error 1
"""

Regards,
Xavier

[xine-devel] xine-lib build broken with libnfs 6

[Xavier B. <xa...@ba...>]

Hi,

While trying to update Fedora to latest libnfs 6 release, a build 
failure with xine-lib can be observed:

```
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../include -I../.. 
-I../../include -I../../include -I../../src -I../../src/xine-engine 
-I../../src/xine-engine -I../../src/xine-utils -I../../src/input 
-I../../src/input -I../../lib -I../../lib -D_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -DNDEBUG -D_REENTRANT -DXINE_COMPILE -O3 
-fexpensive-optimizations -ffast-math -fvisibility=hidden -pipe -Wall 
-Wformat=2 -Wno-format-zero-length -Wmissing-format-attribute 
-Werror-implicit-function-declaration -Wstrict-aliasing=2 
-Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes 
-Wwrite-strings -Wpointer-arith -g -O2 -flto=auto -ffat-lto-objects 
-fexceptions -g -grecord-gcc-switches -pipe -Wall 
-Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 
-Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 
-fcommon -m64 -march=x86-64 -mtune=generic -fasynchronous-unwind-tables 
-fstack-clash-protection -fcf-protection -mtls-dialect=gnu2 
-fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -O3 
-fexpensive-optimizations -ffast-math -Wall -Wchar-subscripts 
-Wnested-externs -Wcast-align -Wmissing-declarations 
-Wmissing-prototypes -Wmissing-format-attribute -Wno-pointer-sign 
-Wformat=2 -Wno-format-zero-length -Wformat-security -Wstrict-aliasing=2 
-Werror=implicit-function-declaration -c input_nfs.c  -fPIC -DPIC -o 
.libs/xineplug_inp_nfs_la-input_nfs.o
make[3]: Leaving directory 
'/builddir/build/BUILD/xine-lib-1.2.13-build/xine-lib-1.2.13/src/input'
input_nfs.c: In function '_read':
input_nfs.c:137:47: error: passing argument 3 of 'nfs_read' makes 
pointer from integer without a cast [-Wint-conversion]
   137 |     rc = nfs_read(this->nfs, this->nfsfh, len - got, buf + got);
       |                                           ~~~~^~~~~
       |                                               |
       |                                               off_t {aka long 
int}
In file included from input_nfs.c:35:
/usr/include/nfsc/libnfs.h:764:27: note: expected 'void *' but argument 
is of type 'off_t' {aka 'long int'}
   764 |                     void *buf, size_t count);
       |                     ~~~~~~^~~
input_nfs.c:137:58: error: passing argument 4 of 'nfs_read' makes 
integer from pointer without a cast [-Wint-conversion]
   137 |     rc = nfs_read(this->nfs, this->nfsfh, len - got, buf + got);
       |                                                      ~~~~^~~~~
       |                                                          |
       |                                                          uint8_t 
* {aka unsigned char *}
/usr/include/nfsc/libnfs.h:764:39: note: expected 'size_t' {aka 'long 
unsigned int'} but argument is of type 'uint8_t *' {aka 'unsigned char 
*'}
   764 |                     void *buf, size_t count);
       |                                ~~~~~~~^~~~~
make[3]: *** [Makefile:1581: xineplug_inp_nfs_la-input_nfs.lo] Error 1
```

Upstream commit : 
https://github.com/sahlberg/libnfs/commit/5e8f7ce273308

qemu is broken too with libnfs 6, here's a comment from upstream libnfs 
author in the subsequent mail thread which might shed some more light on 
what needs to be done for xine-lib and every code broken by the API 
change:

```
I would prefer not to restore the old API. I had to break the API for
at least nfs_[p]read[_async]
in order to make (almost) zero-copy within the library work for the read 
path.
I already do zero-copy (within the library) for the write path bit did
not do it for the read path until now
due to how hairy it is to do with the several variable length fields
in the headers :-(

Since I broke the API for read, which will affect every applicatin I
went ahead and fixed a lot of other warts in the
API as well, so that we can not actually cancel pdus that are in flight.

There is a compile-time check that can be made to determine which API is 
use,
this is from fio :

@@ -157,16 +157,28 @@ static int queue_write(struct fio_libnfs_options
*o, struct io_u *io_u)
  {
         struct nfs_data *nfs_data = io_u->engine_data;

+#ifdef LIBNFS_API_V2
+       return nfs_pwrite_async(o->context, nfs_data->nfsfh,
+                               io_u->buf, io_u->buflen, io_u->offset,
+                               nfs_callback, io_u);
+#else
         return nfs_pwrite_async(o->context, nfs_data->nfsfh, 
io_u->offset,
                                 io_u->buflen, io_u->buf, nfs_callback, 
io_u);
+#endif
  }
...
         struct nfs_data *nfs_data = io_u->engine_data;

+#ifdef LIBNFS_API_V2
+       return nfs_pread_async(o->context, nfs_data->nfsfh,
+                               io_u->buf, io_u->buflen, io_u->offset,
+                               nfs_callback, io_u);
+#else
         return nfs_pread_async(o->context, nfs_data->nfsfh, 
io_u->offset,
                                 io_u->buflen, nfs_callback, io_u);
+#endif

```

Regards,
Xavier

[xine-devel] [PATCH] configure: fix equal operator in test operation

[Andreas B. <li...@im...>]

Hi mailing list,

i'm not sure how to report a bug and post a patch, so i chose this ML.

While trying to build xine-lib within a LibreELEC fork, i ran into the
problem, that ffmpeg headers wasn't found, although they are reported to
be there by pkgconfig. I could narrow down the problem to a wrong test
operator in decoders.m4.
The test operation in configure needs a "=" instead of a "==". This
patch solves that.

Regards
Andreas

Re: [xine-devel] ffmpeg 7 support

[Xavier B. <xa...@ba...>]

Hi Torsten,

Le 2024-05-10 15:50, Torsten Jager a écrit :
> Hi,
> 
>> I got sent this patch in preparation to ffmpeg 7 inclusion in Fedora
>> (Please ignore the part about the specfile, this is obviously 
>> irrelevant
>> here).
> https://sourceforge.net/p/xine/xine-lib-1.2/ci/1e7b184008860c8be2289c3cefd9dee57f06193a/
> (ffmpeg 6.0),
> https://sourceforge.net/p/xine/xine-lib-1.2/ci/73b833e7fe356cd2d9490dda4ebc9bfe16fce958/
> (ffmpeg 7.0, plus a regression fix for the above).
> 

Great, thank you !

>> I believe this is not usable as is, but should give hints as to what
>> needs tweaking.
> Yes, indeed. Those patches are in fact a regional chainsaw massacre.
> They break rv decoding, and they break timing for all other video.
> 
The patch author more or less knew, he called it "hack and slash" and 
hoped for the best. I had a o-so-subtle feeling this was for the worst 
:-)

What about a release ? Last one was more than one year ago.
I've been running a recent xine-lib snapshot together with a xine-ui 
snapshot for a few days without issue (Well, my daughter's rabbit eat 
the net cable, but I guess that is not to be filed in the same category 
as bugs ;-))

Regards,
Xavier

Re: [xine-devel] ffmpeg 7 support

[Torsten J. <t....@gm...>]

Hi,

> I got sent this patch in preparation to ffmpeg 7 inclusion in Fedora
> (Please ignore the part about the specfile, this is obviously irrelevant
> here).
https://sourceforge.net/p/xine/xine-lib-1.2/ci/1e7b184008860c8be2289c3cefd9dee57f06193a/
(ffmpeg 6.0),
https://sourceforge.net/p/xine/xine-lib-1.2/ci/73b833e7fe356cd2d9490dda4ebc9bfe16fce958/
(ffmpeg 7.0, plus a regression fix for the above).

> I believe this is not usable as is, but should give hints as to what
> needs tweaking.
Yes, indeed. Those patches are in fact a regional chainsaw massacre.
They break rv decoding, and they break timing for all other video.

BTW. Surprisingly, I could turn on all new modes with my old post 5.1
snapshot (that did not yet give deprecation warnings), and they work :-)
This pleased me because I probably cannot even build newer ffmpeg with
my old compilers. Years ago, I pretty much failed upgrading just the
compiler on top of a running system :-/

Regards,
Torsten

[xine-devel] ffmpeg 7 support

[Xavier B. <xa...@ba...>]

Hi,

I got sent this patch in preparation to ffmpeg 7 inclusion in Fedora 
(Please ignore the part about the specfile, this is obviously irrelevant 
here).
I believe this is not usable as is, but should give hints as to what 
needs tweaking.
Please kindly take a look.

I'm not even sure xine-lib 1.2.13 has ffmpeg 6 support out of the box. 
Maybe a release would be in order ?

Regards,
Xavier

[xine-devel] dca/dts compilation fix?

[Andrew R. <ran...@gm...>]

tried to compile  latest hg on Slackware 15.0 i586.

Got build error :)

fixed this like attached patch .. not tested real DCA output ... :/.

[xine-devel] Ubuntu 23.04: black screen with vaapi. And how about 4K monitor?

[ТелеБездельник в о. <a.g...@gm...>]

I've been using libxine2 for a long time as the most reliable solution and
not only for xine-ui.

1) However, there are critical problems.
For example, xine-lib-1.2.13 is included with Ubuntu 23.04, but when
installed from the repositories and using the vaapi driver, only audio is
played. No video and black screen.
I don't understand why version 1.2.13 was included with using ffmpeg5.
After all, release 1.2.13 implies a dependence on ffmpeg6.

Below output from Intel G3220, integrated 610 graphics.
Information about libva: VA-API version 1.17.0
libva info: user environment variable asks for driver "i965"
Information about libva: trying to open
/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: initialization function __vaDriverInit_1_8 found
libva info: va_openDriver() returns 0
vaninfo: VA-API version: 1.17 (libva 2.12.0)
Vainfo: Driver Version: Intel i965 Driver for Intel(R) Haswell Desktop
Computers - 2.4.1
vaninfo: supported profile and entry points.
         VAProfileMPEG2Simple: VAEntrypointVLD
         VAProfileMPEG2Simple: VAEntrypointEncSlice
         VAProfileMPEG2Main: VAEntrypointVLD
         VAProfileMPEG2Main: VAEntrypointEncSlice
         VAProfileH264ConstrainedBaseline: VAEntrypointVLD
         VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
         VAProfileH264Main: VAEntrypointVLD
         VAProfileH264Main: VAEntrypointEncSlice
         VAProfileH264High: VAEntrypointVLD
         VAProfileH264High: VAEntrypointEncSlice
         VAProfileH264MultiviewHigh: VAEntrypointVLD
         VAProfileH264MultiviewHigh: VAEntrypointEncSlice
         VAProfileH264StereoHigh: VAEntrypointVLD
         VAProfileH264StereoHigh: VAEntrypointEncSlice
         VAProfileVC1Simple: VAEntrypointVLD
         VAProfileVC1Main: VAEntrypointVLD
         VAProfileVC1Advanced: VAEntrypointVLD
         VAProfileNone: VAEntrypointVideoProc
         VAProfileJPEGBaseline: VAEntrypointVLD
It seems the same will happen with the G5600 but It's a work machine and I
didn't want to install Ubuntu 23.04.

2) There is another problem that I cannot solve. This is xine-ui's
inability to run full screen on a 4K monitor or TV.

I think you know the OpenPLi-PC project, which can be found at
https://github.com/ag1455.
Everything works for me on Ubuntu 20.04. Partially used video_out_vaapi
version 1.2.11, which can be seen in my xine-lib patch.
However, preparations for the 24.04 release do not promise good luck.
Accordingly, I need to patch video_out_vaapi approximately as was done for
opengl and vdpau. The previous developers of the OpenPL-PC project have
disappeared somewhere. But I'm not a programmer.

Re: [xine-devel] Problems with logarithmic volume scaling

[Janek S. <jws...@gm...>]

Hi Torsten,

> O dear. Total confusion with you :-D
Sorry for that - I'm just a regular user, not an expert on writing multimedia libraries :-) And 
thanks for your patience in explaining all of that and for implementing fixes. I trust that this 
is all we need to get things working. In case of problems I'll get in touch.

Unrelated (?) to the volume scaling itself, I also noticed a weird volume bug when playing music 
tracks (mp3) with this newer version of xine (1.2.13). When playing certain tracks the volume 
lowers itself spontaneously. This isn't reflected in the volume sliders in any way - the music 
just becomes slightly quiter. This doesn't happen for all the songs, but if it happens for a 
certain track then it seems to happen in a deterministic way, i.e. if a track is played from the 
beginning then the volume always gets quiter at the same point in the song. This difference in 
volume is really small, but I know my songs and can hear the difference when using headphones.

Cheers,
Janek

> Lets start over at primal slime.
> All mammal ears (including human ones) roughly are double
> logarithmic - for both pitch and volume. Low values will
> be checked at better resolution than high ones intentionally.
> This is
> a) because of the way ears grow themselves internally, and
> b) because this enables us to evaluate sounds made by
>     creatures in a wide range of sizes. This is quite useful
>     for both hunting and escaping predators.
>
> Linear level handling with mere 200 steps does only cover
> part of our ears capabilities (-40dB .. +6dB), and it also
> delivers less and less audible effect the higher the setting
> goes. Your applications can only fix the latter, at the
> expense of reducing the 200 steps even further effectively.
>
> I will _definitely_ keep the libxine internal logarithmic
> stuff. And I now added a radical user switchable reverse fix
> in form of the new config entry "audio.processing.linear_levels".
>
> https://sourceforge.net/p/xine/xine-lib-1.2/ci/142a16a1dd372a028c6f9bf38220
>964c2ffe10d1/
>
> Yes this does reduce value resolution. However, since the
> filter code in your application followes the same basic idea,
> my reverse filter should not make things much worse there.
>
> This will allow you to adjust libxine to the state of your
> applications without libxine rebuild.
> That is, I still recommend to adjust or remove the application
> side volume/eq value filtere. The dB meanings are well
> documented inside <xine.h>.
> I admit that my #if version test was somewhat stupid.
> You better do a runtime test that does not need application
> rebuild for use with various libxine versions:
>
> int major = 0, minor = 0, sub = 0, value;
> value = myslider_get_value (foo->amp_slider);
> xine_get_version (&major, &minor, &sub);
> if (major * 1000000 + minor * 1000 + sub < 1002013) {
>    value = filter_volume_value (value);
> } else {
>    value = (value * 200 + SLIDER_MAX_VALUE / 2) / SLIDER_MAX_VALUE;
> }
> xine_set_param (foo->stream, XINE_PARAM_AUDIO_AMP_LEVEL, value);
>
> And it also allowes you to live test the difference with
> xine-ui: Open the "settings" window (the panel left lower wrench
> symbol), as well as the audio control window (the panel right
> center 5 sliders symbol). Find "processing.linear_levels" in
> the "audio" tab, click it then "Apply", and play with the
> audio sliders in both settings to hear the difference.
> Remember that those sliders always map to 0..200 directly.
>
> Best regards,
> Torsten
>
> --------
> I am 3 letters ahaed of being an Aviator.

Re: [xine-devel] Problems with logarithmic volume scaling

[Janek S. <jws...@gm...>]

Hi Torsten,

I have one more question about xine and changes made to volume scaling. I originally pointed to 
one single commit that modified AO_PROP_AMP behaviour. Were there any other changes to volume 
scaling beside this one? In particular, were there separate changes made for equalizer parameters 
XINE_PARAM_EQ_*HZ?

Cheers,
Janek

Dnia piątek, 30 czerwca 2023, Torsten Jager napisał:
> Hi Janek,
>
> Janek Stolarek <jws...@gm...>
> [xine-devel] Problems with logarithmic volume scaling
>
>  > I'm writing with regards to change in volume scaling introduced
>  > in xine-lib 1.2.12, and more specifically in commit
>  > 59544d4f4a763bd47a5e8b629e1afc74e0c9a719:
>  >
>  > This change only recently made it into stable Debian
>  > (Debian 11 released in 2021 shipped with xine 1.2.10, recently
>  > released Debian 12 ships with xine 1.2.13).
>  > I believe this change adversely affects some xine-based applications
>  > shipped with Trinity Desktop Environment (TDE) such as Amarok and
>  > Kaffeine.
>
> As far as I know, the outside world (most notably Kaffeine) has
> stopped using libxine a long time ago, because of lots of bugs
> and missing features back then :-/
> I myself still use a private fork of Kaffeine 1.2.2 with manually
> added libxine backend. Even that old version already had dropped
> that backend officially.
> I use this because of its very good TV GUI, and added quite a few
> live TV related patches to libxine.
> Nevertheless I havent heard of Kaffeine using xine again so far.
>
>  > For example, lower ranges of the volume scale (say, up to 20%)
>  > have practically the same volume, and perceived change in volume
>  > between 20% and 50% is smaller than between 60% and 68%.
>  > As a result lower range of the volume scale is unusable because
>  > it is too quiet, whereas the upper range lacks granularity
>  > because changes in volume are too large.
>
> My rotten old Kaffeine simply passes the 0..100% volume setting to
> libxine. I found that linear audio scaling not very useful. That
> is why I changed to logarihmic mode (with 0 still meaning silence),
> an documented this inside <xine.h>.
> Works very nice with my Kaffeine :-)
>
>  > This is in contrast with previous linear scaling, where all
>  > volume levels were distinct and it was possible to achieve
>  > desired volume both in lower and upper ranges of the volume scale.
>
> I guess that your Kaffeine (does it really use xine??) performs
> a logarithmic mapping as a workaround on its own, and new libxine
> does it a second time. The best solution would be to limit the
> volume kludge inside Kaffeine to PLAN A:
>
> #if (XINE_MAJOR_VERSION * 10000 + XINE_MINOR_VERSION * 100 +
> XINE_SUB_VERSION < 10213)
> ...
> #endif
>
>  > We are not sure how to proceed here, since this is a deliberate
>  > change in xine and not a bug,
>
> Correct.
>
>  > yet it leads to problematic behaviour in TDE applications.
>  > One possible option would be for TDE to maintain its own version
>  > of xine with this change reverted, but this sounds like a bad
>  > idea.
>  > We were wondering if it would be possible for xine to implement
>  > a new property, say AO_PROP_AMP_LIN (and corresponding
>  > XINE_PARAM_AUDIO_AMP_LEVEL_LIN?) that restores previous linear
>  > volume scaling so that the library client can choose between
>  > linear and logarithmic volume scaling? Is that something
>  > that could happen if we asked nicely?
>
> Logarithmic mode under libxine control only affects
> XINE_PARAM_AUDIO_AMP_LEVEL and XINE_PARAM_EQ_*HZ. I will keep the
> latter logarithmic because the old linear mode makes audio equalizer
> nearly useless. For the former, I added the legacy alternative like
> you suggested:
>
> To use, add PLAN B:
>
> #ifdef XINE_PARAM_AUDIO_LIN_AMP_LEVEL
> #  undef XINE_PARAM_AUDIO_AMP_LEVEL
> #  define XINE_PARAM_AUDIO_AMP_LEVEL XINE_PARAM_AUDIO_LIN_AMP_LEVEL
> #endif
>
> to the relevant kaffeine-xbu source file.
> This still requires adjusting application code, and it also limits
> effective volume value resolution. Again, I think PLAN A is better.
>
> I could also add a new config option or a XINE_PARAM to switch
> behaviour, but that would break transparent enhancement of old
> applications like gxine, or my old Kaffeine.
>
> What do you think?
>
> Best regards,
> Torsten

Re: [xine-devel] Problems with logarithmic volume scaling

[Janek S. <jws...@gm...>]

Hi Torsten,

thanks for your reply.

> As far as I know, the outside world (most notably Kaffeine) has
> stopped using libxine a long time ago, because of lots of bugs
> and missing features back then :-/
Kaffeine and Amarok that I'm referring to are part of Trinity Desktop Environment, which itself is 
derived directly from KDE3. It is in fact KDE3 which got rebranded and is maintained, developed, 
and released for modern Linux distributions to this day. And it does indeed use xine, just like 
in KDE3 days. More information here:

https://www.trinitydesktop.org/

I shall also clarify here that, although I say "we" and "us" a lot when referring to the TDE 
developers team, I myself am just a bug reporter and translator, so I'm not directly involved in 
code development.

> I guess that your Kaffeine (does it really use xine??) performs
> a logarithmic mapping as a workaround on its own
I believe it does not use logaritmic mapping. Here is how Kaffeine sets volume:

https://mirror.git.trinitydesktop.org/gitea/TDE/kaffeine/src/branch/master/kaffeine/src/player-parts/xine-part/kxinewidget.cpp#L2670

And here is how Amarok does it:

https://mirror.git.trinitydesktop.org/gitea/TDE/amarok/src/branch/master/amarok/src/engine/xine/xine-engine.cpp#L577

(Note: for me Amarok is the more important use case, since that's what I use daily.)

> The best solution would be to limit the volume kludge inside Kaffeine to PLAN A:
>
> #if (XINE_MAJOR_VERSION * 10000 + XINE_MINOR_VERSION * 100 +
> XINE_SUB_VERSION < 10213)
> ...
> #endif
Sorry, I'm not sure if I understood what you tried to say here. Do you mean that we could 
implement different volume scaling logic for different xine versions?

> Logarithmic mode under libxine control only affects
> XINE_PARAM_AUDIO_AMP_LEVEL and XINE_PARAM_EQ_*HZ.
To set the volume Amarok uses the former, as witnessed by source code links provided above. And 
then it uses the latter for the equalizer:

https://mirror.git.trinitydesktop.org/gitea/TDE/amarok/src/branch/master/amarok/src/engine/xine/xine-engine.cpp#L655

> I will keep the latter logarithmic because the old linear mode makes audio equalizer
> nearly useless.
Hm... this bit is interesting. I've been using Amarok for the past two decades, always with my 
custom equalizer settings, and I always found it to work as expected. Can you clarify on 
the "nearly useless" bit?

> For the former, I added the legacy alternative like you suggested.
Thanks. Just looked at your latest commit and I admit I don't entirely follow the logic. Does it 
restore the exact same logic as before? Is that an inverse of logaritmic scaling?

> This still requires adjusting application code, and it also limits
> effective volume value resolution.
Can you elaborate on this? Adjusting application code is fine - it can be done by the TDE team. 
I'm concerned about what you said about limited volume value resolution. This is one of the 
problems we want to solve here.

> I could also add a new config option or a XINE_PARAM to switch
> behaviour, but that would break transparent enhancement of old
> applications like gxine, or my old Kaffeine.
>
> What do you think?
I think an ideal solution would be one where:
1. There exist XINE_PARAMs that implement old behaviour exactly as it was, 1-to-1.
2. We can then use those new params to restore the old behaviour.

The best solution I could imagine is one where all parameters revert to their old behaviour, and 
then you add logaritmic volume scaling to use with your private Kaffeine. I realise this is an 
egoistic request, so adding new XINE_PARAMs (also for equalizer) would be fine. This would incur 
some extra work on our side, but that is manageable.

Of course we will still face problems with library versions. Firstly, TDE maintains builds for 
Debian oldstable (one that shipps with xine-1.2.10) so we need to add conditional compilation and 
act accordingly - your PLAN B looks like it would do the job here. Secondly, stable Debian just 
shipped so the new stable release will not ship anytime soon, meaning we'll either be stuck on 
xine-1.2.13 for the next few years or somehow ship it with TDE. But that is for us to figure out.

Once again thank you for your help!

Best regards,
Janek

Re: [xine-devel] Problems with logarithmic volume scaling

[Torsten J. <t....@gm...>]

Hi Janek,

Janek Stolarek <jws...@gm...>
[xine-devel] Problems with logarithmic volume scaling

 > I'm writing with regards to change in volume scaling introduced
 > in xine-lib 1.2.12, and more specifically in commit
 > 59544d4f4a763bd47a5e8b629e1afc74e0c9a719:

 > This change only recently made it into stable Debian
 > (Debian 11 released in 2021 shipped with xine 1.2.10, recently
 > released Debian 12 ships with xine 1.2.13).
 > I believe this change adversely affects some xine-based applications
 > shipped with Trinity Desktop Environment (TDE) such as Amarok and
 > Kaffeine.

As far as I know, the outside world (most notably Kaffeine) has
stopped using libxine a long time ago, because of lots of bugs
and missing features back then :-/
I myself still use a private fork of Kaffeine 1.2.2 with manually
added libxine backend. Even that old version already had dropped
that backend officially.
I use this because of its very good TV GUI, and added quite a few
live TV related patches to libxine.
Nevertheless I havent heard of Kaffeine using xine again so far.

 > For example, lower ranges of the volume scale (say, up to 20%)
 > have practically the same volume, and perceived change in volume
 > between 20% and 50% is smaller than between 60% and 68%.
 > As a result lower range of the volume scale is unusable because
 > it is too quiet, whereas the upper range lacks granularity
 > because changes in volume are too large.

My rotten old Kaffeine simply passes the 0..100% volume setting to
libxine. I found that linear audio scaling not very useful. That
is why I changed to logarihmic mode (with 0 still meaning silence),
an documented this inside <xine.h>.
Works very nice with my Kaffeine :-)

 > This is in contrast with previous linear scaling, where all
 > volume levels were distinct and it was possible to achieve
 > desired volume both in lower and upper ranges of the volume scale.

I guess that your Kaffeine (does it really use xine??) performs
a logarithmic mapping as a workaround on its own, and new libxine
does it a second time. The best solution would be to limit the
volume kludge inside Kaffeine to PLAN A:

#if (XINE_MAJOR_VERSION * 10000 + XINE_MINOR_VERSION * 100 +
XINE_SUB_VERSION < 10213)
...
#endif

 > We are not sure how to proceed here, since this is a deliberate
 > change in xine and not a bug,

Correct.

 > yet it leads to problematic behaviour in TDE applications.
 > One possible option would be for TDE to maintain its own version
 > of xine with this change reverted, but this sounds like a bad
 > idea.
 > We were wondering if it would be possible for xine to implement
 > a new property, say AO_PROP_AMP_LIN (and corresponding
 > XINE_PARAM_AUDIO_AMP_LEVEL_LIN?) that restores previous linear
 > volume scaling so that the library client can choose between
 > linear and logarithmic volume scaling? Is that something
 > that could happen if we asked nicely?

Logarithmic mode under libxine control only affects
XINE_PARAM_AUDIO_AMP_LEVEL and XINE_PARAM_EQ_*HZ. I will keep the
latter logarithmic because the old linear mode makes audio equalizer
nearly useless. For the former, I added the legacy alternative like
you suggested:

To use, add PLAN B:

#ifdef XINE_PARAM_AUDIO_LIN_AMP_LEVEL
#  undef XINE_PARAM_AUDIO_AMP_LEVEL
#  define XINE_PARAM_AUDIO_AMP_LEVEL XINE_PARAM_AUDIO_LIN_AMP_LEVEL
#endif

to the relevant kaffeine-xbu source file.
This still requires adjusting application code, and it also limits
effective volume value resolution. Again, I think PLAN A is better.

I could also add a new config option or a XINE_PARAM to switch
behaviour, but that would break transparent enhancement of old
applications like gxine, or my old Kaffeine.

What do you think?

Best regards,
Torsten

[xine-devel] Problems with logarithmic volume scaling

[Janek S. <jws...@gm...>]

Dear xine developers,

I'm writing with regards to change in volume scaling introduced in xine-lib 1.2.12, and more 
specifically in commit 59544d4f4a763bd47a5e8b629e1afc74e0c9a719:

https://sourceforge.net/p/xine/xine-lib-1.2/ci/59544d4f4a763bd47a5e8b629e1afc74e0c9a719/

This change only recently made it into stable Debian (Debian 11 released in 2021 shipped with xine 
1.2.10, recently released Debian 12 ships with xine 1.2.13). I believe this change adversely 
affects some xine-based applications shipped with Trinity Desktop Environment (TDE) such as 
Amarok and Kaffeine.  For example, lower ranges of the volume scale (say, up to 20%) have 
practically the same volume, and perceived change in volume between 20% and 50% is smaller than 
between 60% and 68%.  As a result lower range of the volume scale is unusable because it is too 
quiet, whereas the upper range lacks granularity because changes in volume are too large.  This 
is in contrast with previous linear scaling, where all volume levels were distinct and it was 
possible to achieve desired volume both in lower and upper ranges of the volume scale.

We are not sure how to proceed here, since this is a deliberate change in xine and not a bug, yet 
it leads to problematic behaviour in TDE applications.  One possible option would be for TDE to 
maintain its own version of xine with this change reverted, but this sounds like a bad idea.  We 
were wondering if it would be possible for xine to implement a new property, say AO_PROP_AMP_LIN 
(and corresponding XINE_PARAM_AUDIO_AMP_LEVEL_LIN?) that restores previous linear volume scaling 
so that the library client can choose between linear and logarithmic volume scaling?  Is that 
something that could happen if we asked nicely?

Best regards,
Janek

Re: [xine-devel] xine-lib-1.2.13 release

[Torsten J. <t....@gm...>]

Hello,

> The tarball that was released yesterday had its topdir named
> xine-lib-1.2. I was about to write about that, as I believe this was a
> mistake. However, I saw another tarball was released today, but now the
> topdir is named xine-lib.1.2.13, which is a bit better but still not the
> usual name pattern. Could we get yet another tarball with an hyphen
> before the version number rather than a dot ?
Changed again ;-)

 > Isn't there a make dist target to produce the tarball ?
I _did_
$ rm .cvsversion
$ make dist
but that made something like xine-lib-1.2.<date>hg<hash>, which stunned
me, and made me change it manually.

 > Anyway, thanks for the release and for the xine-ui release too.
:-))

Torsten

Re: [xine-devel] xine-lib-1.2.13 release

[Xavier B. <xa...@ba...>]

On 23/01/2023 23:18, Torsten Jager wrote:
> Hello,
> 
> I got a release request from Patrick Matthäi <pa...@li...>.
> The pending Dutch translation seems to need more time.
> Thus I suggest release without that for now, and add the translation
> when it is ready.
> I have not set the date in ChangeLog yet.
> 
> Torsten
> 

Hi Torsten,

The tarball that was released yesterday had its topdir named 
xine-lib-1.2. I was about to write about that, as I believe this was a 
mistake. However, I saw another tarball was released today, but now the 
topdir is named xine-lib.1.2.13, which is a bit better but still not the 
usual name pattern. Could we get yet another tarball with an hyphen 
before the version number rather than a dot ?
Isn't there a make dist target to produce the tarball ?

Anyway, thanks for the release and for the xine-ui release too.

Regards,
Xavier

[xine-devel] xine-lib-1.2.13 release

[Torsten J. <t....@gm...>]

Hello,

I got a release request from Patrick Matthäi <pa...@li...>.
The pending Dutch translation seems to need more time.
Thus I suggest release without that for now, and add the translation
when it is ready.
I have not set the date in ChangeLog yet.

Torsten

[xine-devel] Using controls on xine panel crashes xine, except on skylake

[Ken M. <zar...@nt...>]

For about 2 years, on most of my machines I've been unable to use the
panel controls in xine - even clicking on the pause symbol, or
moving the position slider cause xine to crash.  Doing this from a
controlling terminal I see

xiTK received SIGSEGV signal, RIP.
Aborted

This is on x86_64 linux, beyond linuxfromscratch since the days when
gcc-10.2.0 and glibc-2.32 were current (in those days,
xine-lib-1.2.10 and xine-ui-0.99.12).  HOWEVER, at that time there
was a reprot that the panel worked fine on intel skylake with the
intel xorg driver.  At that time I did not have an available skylake
desktop system and assumed something in my own builds must be the
cause.

Recently I've come back to ripping my DVDs before machines with DVD
drives disappear, and I can confirm that with the following hardware
(all with integrated graphics) the panel crashes:

zen2 ryzen 7 4750G
zen1+ ryzen 5 3400G
haswell i7 4790

My low-end skylake is now usable as a desktop, and there xine's
panel works fine whether I use the modesetting or intel xorg drivers.

My current versions are:

xine-lib-1.2.12
xine-ui-0.99.13

with mesa-22.1.4 (iris driver on skylake, crocus on haswell,
radeonsi on the others).

I realise that the userbase for xine-ui is probably quite low, and
it may well be that something in my builds is wrong, but I'd
appreciate guidance on where I should be looking to try to track
down the problem.

At one point I'd guessed soem of my CFLAGS or CXXFLAGS were likely
to be the problem (normal -march and hardening), but on the 3400G
I'm not using my own CFLAGS whereas I am on the others including the
skylake, and anyway I've now realised that xine-lib defaults to more
aggrssive optimizations (and overriding those doesn't help this
problem).

TIA,

ĸen
-- 
(Rincewind) was pretty sure there was no way you could get a cross
between a human and a sheep.  If there was, people would definitely
have found out by now.            -- The Last Continent

Re: [xine-devel] xine-lib-1.2.12 and ffmpeg-5.1

[Ken M. <zar...@nt...>]

On Fri, Jul 29, 2022 at 06:28:46PM +0100, Ken Moffat via xine-devel wrote:
> With ffmpeg-5.1, xine-lib-1.2.12 FTBFS.
> 
> First error is
> 
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../include -I../../.. -I../../../include
> -I../../../include -I../../../src -I../../../src/xine-engine -I../../../src/xine-engine
> -I../../../src/xine-utils -I../../../src/input -I../../../src/input -I../../../lib -I../../../lib
> -DNDEBUG -D_REENTRANT -DXINE_COMPILE -O3 -fexpensive-optimizations -ffast-math -fvisibility=hidden
> -pipe -Wall -Wformat=2 -Wno-format-zero-length -Wmissing-format-attribute
> -Werror-implicit-function-declaration -Wstrict-aliasing=2 -Wchar-subscripts -Wmissing-declarations
> -Wmissing-prototypes -Wwrite-strings -Wpointer-arith -O3 -march=native -mtune=native
> -fstack-clash-protection -D_FORTIFY_SOURCE=2 -fstack-protector-strong -O3 -fexpensive-optimizations
> -ffast-math -Wall -Wchar-subscripts -Wnested-externs -Wcast-align -Wmissing-declarations
> -Wmissing-prototypes -Wmissing-format-attribute -Wno-pointer-sign -Wformat=2
> -Wno-format-zero-length -Wformat-security -Wstrict-aliasing=2 -Werror=implicit-function-declaration
> -MT xineplug_decode_ff_la-input_avio.lo -MD -MP -MF .deps/xineplug_decode_ff_la-input_avio.Tpo -c
> input_avio.c  -fPIC -DPIC -o .libs/xineplug_decode_ff_la-input_avio.o
> input_avio.c: In function 'input_avio_seek_time':
> input_avio.c:128:45: error: 'AV_TIME_BASE' undeclared (first use in this function); did you mean
> 'LC_TIME_MASK'?
>   128 |     int64_t ts     = (int64_t)time_offset * AV_TIME_BASE / 1000;
>       |                                             ^~~~~~~~~~~~
>       |                                             LC_TIME_MASK
> input_avio.c:128:45: note: each undeclared identifier is reported only once for each function it
> appears in
> make[4]: *** [Makefile:817: xineplug_decode_ff_la-input_avio.lo] Error 1
> 
> and it looks as if there are other ffmpeg-related errors.
> 
> I was also surprised that when I tried 'make -j1' in case it was a
> race, there were some other unfin ished jobs.  But that part is no
> big deal.
> 
> ĸen

As a workaround for ffmpeg-5.1 I've been given the following couple
of seds. Obviously this is not a proper fix, but it allows xine-lib
to build, and xine-ui to work "as it did before".

sed -e '/\/avformat.h/i #include <libavcodec/version.h>' \
    -i src/combined/ffmpeg/demux_avformat.c
sed -e '/\/avio.h/i #include <libavutil/avutil.h>' \
    -i src/combined/ffmpeg/input_avio.c

ĸen
-- 
 It is very easy to get ridiculously confused about the tenses of
 time travel, but most things can be resolved by a sufficiently
 large ego.        -- The Last Continent

[xine-devel] xine-lib-1.2.12 and ffmpeg-5.1

[Ken M. <zar...@nt...>]

With ffmpeg-5.1, xine-lib-1.2.12 FTBFS.

First error is

libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../include -I../../.. -I../../../include
-I../../../include -I../../../src -I../../../src/xine-engine -I../../../src/xine-engine
-I../../../src/xine-utils -I../../../src/input -I../../../src/input -I../../../lib -I../../../lib
-DNDEBUG -D_REENTRANT -DXINE_COMPILE -O3 -fexpensive-optimizations -ffast-math -fvisibility=hidden
-pipe -Wall -Wformat=2 -Wno-format-zero-length -Wmissing-format-attribute
-Werror-implicit-function-declaration -Wstrict-aliasing=2 -Wchar-subscripts -Wmissing-declarations
-Wmissing-prototypes -Wwrite-strings -Wpointer-arith -O3 -march=native -mtune=native
-fstack-clash-protection -D_FORTIFY_SOURCE=2 -fstack-protector-strong -O3 -fexpensive-optimizations
-ffast-math -Wall -Wchar-subscripts -Wnested-externs -Wcast-align -Wmissing-declarations
-Wmissing-prototypes -Wmissing-format-attribute -Wno-pointer-sign -Wformat=2
-Wno-format-zero-length -Wformat-security -Wstrict-aliasing=2 -Werror=implicit-function-declaration
-MT xineplug_decode_ff_la-input_avio.lo -MD -MP -MF .deps/xineplug_decode_ff_la-input_avio.Tpo -c
input_avio.c  -fPIC -DPIC -o .libs/xineplug_decode_ff_la-input_avio.o
input_avio.c: In function 'input_avio_seek_time':
input_avio.c:128:45: error: 'AV_TIME_BASE' undeclared (first use in this function); did you mean
'LC_TIME_MASK'?
  128 |     int64_t ts     = (int64_t)time_offset * AV_TIME_BASE / 1000;
      |                                             ^~~~~~~~~~~~
      |                                             LC_TIME_MASK
input_avio.c:128:45: note: each undeclared identifier is reported only once for each function it
appears in
make[4]: *** [Makefile:817: xineplug_decode_ff_la-input_avio.lo] Error 1

and it looks as if there are other ffmpeg-related errors.

I was also surprised that when I tried 'make -j1' in case it was a
race, there were some other unfin ished jobs.  But that part is no
big deal.

ĸen
-- 
 It is very easy to get ridiculously confused about the tenses of
 time travel, but most things can be resolved by a sufficiently
 large ego.        -- The Last Continent