media-libs/libdts is deprecated and apps should be using libdca now, renamed by upstream so moving on.. please do xine-lib-1.1.8 bug same time with this one, as current stable doesn't support libdca. thanks.
Site http://www.sr.se/cgi-bin/mall/index.asp?programid=2445 has some example DTS files you can use for testing.
media-libs/libdca-0.0.5 on AMD64: Emerges fine, no collisions. Works, tested with media-video/mplayer-1.0_rc1_p20070824 with dts USE flag and the included dtsdec program. Portage 2.1.3.9 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.5-r4, 2.6.23-rc1 x86_64) ================================================================= System uname: 2.6.23-rc1 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Timestamp of tree: Sat, 15 Sep 2007 13:00:01 +0000 app-shells/bash: 3.2_p17 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=nocona -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks metadata-transfer multilib-strict sandbox sfperms strict test unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.osuosl.org/ http://distro.ibiblio.org/pub/linux/distributions/gentoo/ http://www.gtlib.gatech.edu/pub/gentoo " MAKEOPTS="-j3" PKGDIR="/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aac acl alsa amd64 berkdb bitmap-fonts cli cracklib crypt cups dbus dri examples flac fortran gdbm gpm hal iconv isdnlog jpeg kde kdeenablefinal mad midi mmx mp3 mpeg mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre perl png pppd python qt4 readline reflection session spl sse sse2 ssl symlink tcpd test truetype truetype-fonts type1-fonts unicode vorbis xml xorg zlib" ALSA_CARDS="usb-audio hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Hmm, why does media-libs/libdca block media-libs/libdts, but not the other way round?
amd64 stable
(In reply to comment #3) > Hmm, why does media-libs/libdca block media-libs/libdts, but not the other way > round? > Because Portage can handle reverse blockers I believe.
Stable for HPPA.
x86 stable
On Sparc, this builds and installs routinely. However, it has no built-in tests and I have no way to test it, so I myself cannot keyword it without some help. From the description, I suppose this would be verification as a libdts replacement. But that doesn't help because my systems have no use for supporting soundstreams --- no audio support.
ppc stable.
(In reply to comment #8) > On Sparc, this builds and installs routinely. However, it has no built-in > tests and I have no way to test it, so I myself cannot keyword it without some > help. From the description, I suppose this would be verification as a libdts > replacement. But that doesn't help because my systems have no use for > supporting soundstreams --- no audio support. > In order to test it you can grab samples at : http://samples.mplayerhq.hu/A-codecs/DTS/ I've patched vlc 0.8.6b_beta1 to be compatible with this version, so you can just try USE="dts" emerge vlc and then run "vlc your_just_grabbed_dts_file" you can also try dcadec that is shipped with libdca, "dcadec -o wav my_dts_file > foo.wav" and then just play it with your favorite audio player ;) (betware of the ">", it outputs binary to stdout and made unusable my $TERM several times) (copy/paste from bug #175164)
Um, my main point was that I do not have audio devices in any of my systems. :)
(In reply to comment #11) > Um, my main point was that I do not have audio devices in any of my systems. :) Bah... I missed the 's' ;) shame on me Then I dunno how I could help you, besides providing you md5's of decoded wav files to mimic a test.
Going through the dcadec procedure you suggest with a file from http://samples.mplayerhq.hu/A-codecs/DTS/ runs and produces an output file. I'm going to play with the resulting file on a system with good sound support. It's just that that system is not sparc --- that doesn't matter, I think. Surely the resulting .wav file from "dcadec -o wav ... > ..." is system-neutral. I don't need sound on the system where I make the file; the file I make has to play on a system with sound. :)
sparc stable
If media-libs/libdts is deprecated, you need to stabilize >ffmpeg/ffmpeg-0.4.9_p20070330 since this version has a dependency on media-libs/libdts.
alpha/ia64 stable, thanks Tobias
ppc64 stable
Ok.If libdts is deprecated, I understand now why package with the dts USE flag enabled try to install the dca package. But then I guess in this context, there should be a new "dca" USE flag. Of course "dts" should still exist for a while and continue to redirect to dca for compatibility for current portage's configuration. But a "(deprecated: use dca now)" should be add to its description.
(In reply to comment #18) > Ok.If libdts is deprecated, I understand now why package with the dts USE flag > enabled try to install the dca package. But then I guess in this context, there > should be a new "dca" USE flag. Of course "dts" should still exist for a while > and continue to redirect to dca for compatibility for current portage's > configuration. But a "(deprecated: use dca now)" should be add to its > description. > imho we should only update the use flag description, dts is a format afaik, thus dts useflag makes sense. but the description might be a bit confusing: dts - Enables libdts (DTS Coherent Acoustics decoder) support I'd suggest changing it to: dts - Enables DTS Coherent Acoustics decoder support @other sound people: any thoughts ?
This sounds ok for me.
Oh a question that I wondered after I made some search about what was precisely this DTS Coherent Acoustics technology (thanks Wikipedia ;-). Apparently libdca is not another library providing same service, but the new name of the libdts library. In this case, isn't there a mean through portage that -- even though they have different names -- libdca can be considered as an upgrade of libdts? The reason of this question is that as libdts was already installed, libdca's installation was blocked by presence of libdts. I had then to unmerge it first (so 2 steps instead of one and some time checking dependencies, and wondering what was exactly this library). So I was thinking that maybe portage could do it itself if there could be some flag telling it that this is simply a name change... But maybe is it difficult if the name change was also accompanied by some API change? Or maybe simply dependency problems because any build before and after the upgrade would look for different named library (but for this, if API is similar, I was thinking that some symlink could solve the issue, could it?)? Bye.
yes, we can do a packagemove so that it can be considered as an upgrade; but if we do so, that'll probably break arm and sh stable systems since they don't have any libdca stable. (please correct me if I'm wrong on the packagemove behavior though)
(In reply to comment #19) > I'd suggest changing it to: > dts - Enables DTS Coherent Acoustics decoder support > @other sound people: any thoughts ? I've just changed it per your suggestion. Just do it(tm) ;-)
arm stable
