Log in

View Full Version : Aften 0.0.8 is out

Pages : 1 2 3 4 5 6 7 8 9 10 11 [12] 13 14 15 16 17 18 19 20 21 22 23
Chainmax
27th April 2007, 16:45
This is progressing very nicely, thanks for the new release Justin :).
Fizick
30th April 2007, 22:14
When I try open in IE or Opera the link:
http://kurtnoise.free.fr/index.php?dir=Aften/

I have got an error message only:

Incorrect format for file ./languages/ru.txt on line 1.
Format is "variable name[tab]value"
tebasuna51
30th April 2007, 23:47
Waiting for a windows binary aften 0.07 (the last 0.06 have problems with big files) I recommend use aften rev490 24 April 2007, from wisodev.

Changes 491, 492 and 493, 25 April 2007, are only in text files (readme, changelog, cmakelist) without changes in functionality.

Edit: link removed because aften 0.07 by Wisodev (thanks to you) available.
Kurtnoise
1st May 2007, 08:51
When I try open in IE or Opera the link:
http://kurtnoise.free.fr/index.php?dir=Aften/

I have got an error message only:

Incorrect format for file ./languages/ru.txt on line 1.
Format is "variable name[tab]value"


Use the old entry instead : http://kurtnoise.free.fr/Aften ...There is a bug in the PHP code for the russian language detection.


About a new compile : still doesn't work properly here...Maybe Wisodev should try himself coz he doesn't use CMake files for compilation.
wisodev
1st May 2007, 09:41
Here are my Aften version 0.07 optimized builds for Win32 and Win64.

Download binaries for Win32:
aften-0.07-win32-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.zip?download) (2 658 303 bytes)
aften-0.07-win32-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.rar?download) (501 676 bytes)
aften-0.07-win32-bin.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.7z?download) (493 666 bytes)
Download binaries for Win64:
aften-0.07-win64-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.zip?download) (881 151 bytes)
aften-0.07-win64-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.rar?download) (320 881 bytes)
aften-0.07-win64-bin.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.7z?download) (306 845 bytes)
Download my patched sources with build scripts:
aften-0.07-src.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.zip?download) (159 557 bytes)
aften-0.07-src.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.rar?download) (82 861 bytes)
aften-0.07-src.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.7z?download) (81 052 bytes)

Official website (http://win32builds.sourceforge.net/aften/index.html) for my builds.

Thanks,
wisodev
Chumbo
1st May 2007, 17:26
Here are my Aften version 0.07 optimized builds for Win32 and Win64.

Download binaries for Win32:
aften-0.07-win32-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.zip?download) (2 658 303 bytes)
aften-0.07-win32-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.rar?download) (501 676 bytes)
aften-0.07-win32-bin.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win32-bin.7z?download) (493 666 bytes)
Download binaries for Win64:
aften-0.07-win64-bin.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.zip?download) (881 151 bytes)
aften-0.07-win64-bin.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.rar?download) (320 881 bytes)
aften-0.07-win64-bin.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-win64-bin.7z?download) (306 845 bytes)
Download my patched sources with build scripts:
aften-0.07-src.zip (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.zip?download) (159 557 bytes)
aften-0.07-src.rar (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.rar?download) (82 861 bytes)
aften-0.07-src.7z (http://prdownloads.sourceforge.net/win32builds/aften-0.07-src.7z?download) (81 052 bytes)

Official website (http://win32builds.sourceforge.net/aften/index.html) for my builds.

Thanks,
wisodev

VERY much appreciated wisodev! :)
Mr_Odwin
2nd May 2007, 16:35
Does "optimised for win32 and win64" mean that they won;t work on the other operating system. I.e. will the win32 version work all right on a win64 system?
And, is there a version that will work on a generic processor? (If you were including aften as part of a download package which version from the packs above should be chosen to be compatible with all processors?)
Boulder
2nd May 2007, 16:51
I believe that there's an MMX build in the package which would work on most processors.
wisodev
2nd May 2007, 17:32
Does "optimised for win32 and win64" mean that they won;t work on the other operating system. I.e. will the win32 version work all right on a win64 system?
And, is there a version that will work on a generic processor? (If you were including aften as part of a download package which version from the packs above should be chosen to be compatible with all processors?)

The Win32 builds work under Win64 operating systems (for example they work without any problems under Windows XP x64, Windows Server 2003 x64 and Vista x64). The Win64 binaries are native binaries so they only work under Win64 OS.

The most generic binary is placed in exe_pgo directory (win32 binaries archive) and it is the most compatible build to include in any software pack.
DarkAvenger
5th May 2007, 13:35
@kurtnoise

I tried the svn version on AthlonXP with linux x86 - and no probs. Do you have the same problem with svn version, as well? It would really be helpfull if you could find out where exactly the crash occurs. Maybe you could compile with CFLAGS="-O0 -g3" (delete cmake cache before) and try gdb again.
Kurtnoise
7th May 2007, 09:41
Hi,

Sorry for the delay...So here it is :
(gdb) run -b 448 ~/Des_accords.wav ~/Test1.ac3
Starting program: /home/lionel/aften/default/aften -b 448 ~/Des_accords.wav ~/Test1.ac3
Failed to read a valid object file image from memory.
[Thread debugging using libthread_db enabled]
[New Thread -1210759488 (LWP 9234)]

Aften: A/52 audio encoder
Version SVN-r508
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: Signed 16-bit 44100 Hz stereo
output format: 44100 Hz stereo (2/0)


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210759488 (LWP 9234)]
0x0806c2ea in sse2_process_exponents ()
(gdb)

I used gcc 4.1 / nasm 0.98.38 . I'm running on Debian Sid 4.0 with an AMD 64 3200+. Same crash with 0.07 bundle or svn build. Is that enough ?
SealTooGreat
7th May 2007, 09:53
Does Aften support WAV 7 channel input. If does, what is the channel order mapping. I want to encode to AC3 6.1 EX with "LFE channel is present"
Which program can I use to connect 7 separated mono WAV? Cause Sound Forge doesn't allow me that kind of exporting.
BTW those 7 channels are created from stereo using Sony Sound Forge 9 + SRS Circle Surround VST Pro Decoder.
One more thing, can Aften handle separated mono wav input?
Sorry if I've asked same repeated questions, didn't have time to read whole thread and in downloaded EncWAVtoAC3-0.4-bin I couldn't find that info.
jruggle
7th May 2007, 10:22
Does Aften support WAV 7 channel input. If does, what is the channel order mapping. I want to encode to AC3 6.1 EX with "LFE channel is present"
Which program can I use to connect 7 separated mono WAV? Cause Sound Forge doesn't allow me that kind of exporting.
BTW those 7 channels are created from stereo using Sony Sound Forge 9 + SRS Circle Surround VST Pro Decoder.
One more thing, can Aften handle separated mono wav input?
Sorry if I've asked same repeated questions, didn't have time to read whole thread and in downloaded EncWAVtoAC3-0.4-bin I couldn't find that info.
From what little I know about it, I think that EX is still 5.1, but emulates 6.1 by matrixing a rear surround into the left and right surround. AC-3 does not support more than 5.1 channels. E-AC-3 supports it, but Aften does not encode E-AC-3 yet.
SealTooGreat
7th May 2007, 11:53
... but Aften does not encode E-AC-3 yet.
Are You sure that E-AC-3 will supported in the future?
jruggle
8th May 2007, 10:07
Are You sure that E-AC-3 will supported in the future?
Yes. I thought about implementing it soon, but I really don't have a way to test the output. But by the end of the summer there will be an open-source E-AC-3 decoder, so that will allow me to do proper testing.
chros
9th May 2007, 09:39
Yes. I thought about implementing it soon, but I really don't have a way to test the output. But by the end of the summer there will be an open-source E-AC-3 decoder, so that will allow me to do proper testing.
You can use gabest's ac3filter modified by orbitlee and Sonic Decoder Pack 4.2 to try out eac3 files.
Kurtnoise
9th May 2007, 11:27
Justin doesn't run on Windows and Sonic bundle is a shareware...;)
chros
9th May 2007, 14:46
Justin doesn't run on Windows...
Ahaa, I get it ! :)
jruggle
10th May 2007, 01:15
Justin doesn't run on Windows and Sonic bundle is a shareware...;)

Ahaa, I get it ! :)

Yeah, I should've mentioned that. I don't charge for software, and I don't pay for software. I figure that if I really have a need for something that isn't already implemented in open source, I should do it myself. In this case, I'm at least helping out by mentoring a student who is producing an E-AC-3 decoder for FFmpeg as part of Google's Summer of Code program.
Kurtnoise
14th May 2007, 10:15
@Justin or Prakash : any news about my segfault ?

More gdb infos :
lionel@debian:~/aften/default$ gdb ./aften
GNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
(gdb) run -b 448 ~/Club.wav ~/Test2.ac3
Starting program: /home/lionel/aften/default/aften -b 448 ~/Club.wav ~/Test2.ac3
[Thread debugging using libthread_db enabled]
[New Thread -1210399040 (LWP 7929)]

Aften: A/52 audio encoder
Version SVN-r508
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: Signed 16-bit 44100 Hz stereo
output format: 44100 Hz stereo (2/0)


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1210399040 (LWP 7929)]
0x0806cd13 in sse2_process_exponents ()
(gdb) bt
#0 0x0806cd13 in sse2_process_exponents ()
#1 0xb7eeb120 in ?? () from /lib/tls/i686/cmov/libc.so.6
#2 0x00000219 in ?? ()
#3 0xb7eeb144 in ?? () from /lib/tls/i686/cmov/libc.so.6
#4 0xb7eeb144 in ?? () from /lib/tls/i686/cmov/libc.so.6
#5 0x00000000 in ?? ()
(gdb) disass $pc-32 $pc+32
Dump of assembler code from 0x806ccf3 to 0x806cd33:
0x0806ccf3 <sse2_process_exponents+6147>: pushf
0x0806ccf4 <sse2_process_exponents+6148>: and $0xc8,%al
0x0806ccf6 <sse2_process_exponents+6150>: add %al,(%eax)
0x0806ccf8 <sse2_process_exponents+6152>: add %cl,0xdc24ac(%ebx)
0x0806ccfe <sse2_process_exponents+6158>: add %al,(%eax)
0x0806cd00 <sse2_process_exponents+6160>: test %esi,%esi
0x0806cd02 <sse2_process_exponents+6162>: mov 0xfffffffc(%ebp,%ebx,4),%ecx
0x0806cd06 <sse2_process_exponents+6166>: jle 0x806d17b <sse2_process_exponents+7307>
0x0806cd0c <sse2_process_exponents+6172>: mov 0xb4(%esp),%ebx
0x0806cd13 <sse2_process_exponents+6179>: movdqu (%ecx),%xmm0
0x0806cd17 <sse2_process_exponents+6183>: movdqa %xmm5,%xmm2
0x0806cd1b <sse2_process_exponents+6187>: mov $0x10,%edx
0x0806cd20 <sse2_process_exponents+6192>: lea 0xffffffff(%ebx),%eax
0x0806cd23 <sse2_process_exponents+6195>: mov 0xcc(%esp),%ebx
0x0806cd2a <sse2_process_exponents+6202>: shr $0x4,%eax
0x0806cd2d <sse2_process_exponents+6205>: and $0x1,%eax
0x0806cd30 <sse2_process_exponents+6208>: cmpl $0x10,0xb4(%esp)
End of assembler dump.
(gdb) info all-registers
eax 0x6 6
ecx 0x30303060 808464480
edx 0x3 3
ebx 0xf0 240
esp 0xbfa5de10 0xbfa5de10
ebp 0xbfa5e528 0xbfa5e528
esi 0xf0 240
edi 0x5 5
eip 0x806cd13 0x806cd13 <sse2_process_exponents+6179>
eflags 0x210206 [ PF IF RF ID ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0 0
gs 0x33 51
st0 3.5821711910336390903074238806631572e-15 (raw 0x3fcf810fb2958f648000)
st1 -2.4515507845990214264020323753356934e-08 (raw 0xbfe5d2962c0000000000)
st2 6.5240285009447156406362713407295607e-11 (raw 0x3fdd8f7703f1baf3d152)
st3 -5.9851242184549846570007503032684326e-08 (raw 0xbfe780879---Type <return> to continue, or q <return> to quit---
18000000000)
st4 -4.7593488261554739437997341156005859e-08 (raw 0xbfe6cc69980000000000)
st5 3.5335734338559632305987179279327393e-08 (raw 0x3fe697c40d0000000000)
st6 0 (raw 0x00000000000000000000)
st7 16777216 (raw 0x40178000000000000000)
fctrl 0x37f 895
fstat 0x20 32
ftag 0xffff 65535
fiseg 0x0 0
fioff 0x0 0
foseg 0x0 0
fooff 0x0 0
fop 0x0 0
xmm0 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0, 0x0, 0x12, 0x12, 0x0, 0x0, 0x12, 0x12, 0x0, 0x0, 0x13,
0x13, 0x0, 0x0, 0x13, 0x13}, v8_int16 = {0x0, 0x1212, 0x0, 0x1212, 0x0,
0x1313, 0x0, 0x1313}, v4_int32 = {0x12120000, 0x12120000, 0x13130000,
0x13130000}, v2_int64 = {0x1212000012120000, 0x1313000013130000},
uint128 = 0x13130000131300001212000012120000}
xmm1 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0, 0x0, 0x14, 0x14, 0x0, 0x0, 0x12, 0x12, 0x0, 0x0, 0x12,
---Type <return> to continue, or q <return> to quit---
0x12, 0x0, 0x0, 0x14, 0x14}, v8_int16 = {0x0, 0x1414, 0x0, 0x1212, 0x0,
0x1212, 0x0, 0x1414}, v4_int32 = {0x14140000, 0x12120000, 0x12120000,
0x14140000}, v2_int64 = {0x1212000014140000, 0x1414000012120000},
uint128 = 0x14140000121200001212000014140000}
xmm2 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0, 0x12, 0x0, 0x0, 0x0, 0x12, 0x0, 0x0, 0x0, 0x13, 0x0, 0x0,
0x0, 0x13, 0x0, 0x0}, v8_int16 = {0x1200, 0x0, 0x1200, 0x0, 0x1300, 0x0,
0x1300, 0x0}, v4_int32 = {0x1200, 0x1200, 0x1300, 0x1300}, v2_int64 = {
0x120000001200, 0x130000001300},
uint128 = 0x00001300000013000000120000001200}
xmm3 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x14, 0x14, 0x14, 0x14, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12,
0x12, 0x12, 0x14, 0x14, 0x14, 0x14}, v8_int16 = {0x1414, 0x1414, 0x1212,
0x1212, 0x1212, 0x1212, 0x1414, 0x1414}, v4_int32 = {0x14141414,
0x12121212, 0x12121212, 0x14141414}, v2_int64 = {0x1212121214141414,
0x1414141412121212}, uint128 = 0x14141414121212121212121214141414}
xmm4 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x14, 0x16, 0x16,
0x16, 0x16, 0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x1414, 0x1414, 0x1414,
0x1414, 0x1616, 0x1616, 0x0, 0x0}, v4_int32 = {0x14141414, 0x14141414,
0x16161616, 0x0}, v2_int64 = {0x1414141414141414, 0x16161616},
uint128 = 0x00000000161616161414141414141414}
xmm5 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
---Type <return> to continue, or q <return> to quit---
v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0},
uint128 = 0x00000000000000000000000000000000}
xmm6 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x0, 0x14, 0x0, 0x0, 0x0, 0x14, 0x0, 0x0, 0x0, 0x16, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0}, v8_int16 = {0x1400, 0x0, 0x1400, 0x0, 0x1600, 0x0,
0x0, 0x0}, v4_int32 = {0x1400, 0x1400, 0x1600, 0x0}, v2_int64 = {
0x140000001400, 0x1600}, uint128 = 0x00000000000016000000140000001400}
xmm7 {v4_float = {0x0, 0x0, 0x0, 0x0}, v2_double = {0x0, 0x0},
v16_int8 = {0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x12, 0x13, 0x13,
0x13, 0x13, 0x13, 0x13, 0x13, 0x13}, v8_int16 = {0x1212, 0x1212, 0x1212,
0x1212, 0x1313, 0x1313, 0x1313, 0x1313}, v4_int32 = {0x12121212,
0x12121212, 0x13131313, 0x13131313}, v2_int64 = {0x1212121212121212,
0x1313131313131313}, uint128 = 0x13131313131313131212121212121212}
mxcsr 0x1fa0 [ PE IM DM ZM OM UM PM ]
mm0 {uint64 = 0x810fb2958f648000, v2_int32 = {0x8f648000,
0x810fb295}, v4_int16 = {0x8000, 0x8f64, 0xb295, 0x810f}, v8_int8 = {0x0,
0x80, 0x64, 0x8f, 0x95, 0xb2, 0xf, 0x81}}
mm1 {uint64 = 0xd2962c0000000000, v2_int32 = {0x0, 0xd2962c00},
v4_int16 = {0x0, 0x0, 0x2c00, 0xd296}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x2c, 0x96, 0xd2}}
mm2 {uint64 = 0x8f7703f1baf3d152, v2_int32 = {0xbaf3d152,
0x8f7703f1}, v4_int16 = {0xd152, 0xbaf3, 0x3f1, 0x8f77}, v8_int8 = {0x52,
---Type <return> to continue, or q <return> to quit---
0xd1, 0xf3, 0xba, 0xf1, 0x3, 0x77, 0x8f}}
mm3 {uint64 = 0x8087918000000000, v2_int32 = {0x0, 0x80879180},
v4_int16 = {0x0, 0x0, 0x9180, 0x8087}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x80,
0x91, 0x87, 0x80}}
mm4 {uint64 = 0xcc69980000000000, v2_int32 = {0x0, 0xcc699800},
v4_int16 = {0x0, 0x0, 0x9800, 0xcc69}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
0x98, 0x69, 0xcc}}
mm5 {uint64 = 0x97c40d0000000000, v2_int32 = {0x0, 0x97c40d00},
v4_int16 = {0x0, 0x0, 0xd00, 0x97c4}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0,
0xd, 0xc4, 0x97}}
mm6 {uint64 = 0x0, v2_int32 = {0x0, 0x0}, v4_int16 = {0x0, 0x0,
0x0, 0x0}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}}
mm7 {uint64 = 0x8000000000000000, v2_int32 = {0x0, 0x80000000},
v4_int16 = {0x0, 0x0, 0x0, 0x8000}, v8_int8 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x80}}
(gdb)
Hope this helps...I've also reported the bug on SF just for reminding.
DarkAvenger
16th May 2007, 21:23
Well, it's crashing at this instruction


0x0806cd13 <sse2_process_exponents+6179>: movdqu (%ecx),%xmm0


It is an unaligned load, so it can't crash because of alignment issues. Could you try running aften with valgrind? I really don't understand why it crashes there. Could you try a different compiler?
Kurtnoise
17th May 2007, 07:30
Could you try running aften with valgrind?
lionel@debian:~/aften/default$ valgrind --tool=memcheck ./aften -b 448 ~/Club.wav ~/Test2.ac3
==5771== Memcheck, a memory error detector.
==5771== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==5771== Using LibVEX rev 1658, a library for dynamic binary translation.
==5771== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==5771== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework.
==5771== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==5771== For more details, rerun with: -v
==5771==

Aften: A/52 audio encoder
Version SVN-r508
(c) 2006-2007 Justin Ruggles, Prakash Punnoor, et al.

input format: Signed 16-bit 44100 Hz stereo
output format: 44100 Hz stereo (2/0)

==5771== Use of uninitialised value of size 4
==5771== at 0x806CD13: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771== by 0x41D3C03: ???
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806CDAB: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771== by 0x41D3C03: ???
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806CDB0: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771== by 0x41D3C03: ???
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806CE90: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Conditional jump or move depends on uninitialised value(s)
==5771== at 0x4022E75: memcpy (mc_replace_strmem.c:77)
==5771== by 0x806C4EC: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Conditional jump or move depends on uninitialised value(s)
==5771== at 0x4022E8A: memcpy (mc_replace_strmem.c:406)
==5771== by 0x806C4EC: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Conditional jump or move depends on uninitialised value(s)
==5771== at 0x4022EDF: memcpy (mc_replace_strmem.c:406)
==5771== by 0x806C4EC: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x4022EF1: memcpy (mc_replace_strmem.c:406)
==5771== by 0x806C4EC: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D089: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D0BA: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D0D7: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D0E2: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D0ED: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D0F8: sse2_process_exponents (in /home/lionel/aften/default/aften)
==5771==
==5771== Use of uninitialised value of size 4
==5771== at 0x806D103: sse2_process_exponents (in /home/lionel/aften/default/aften)
progress: 100% | q: 322.0 | bw: 60.0 | bitrate: 448.0 kbps

==5771==
==5771== ERROR SUMMARY: 494513 errors from 15 contexts (suppressed: 15 from 1)
==5771== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5771== malloc/free: 6,902 allocs, 6,902 frees, 42,562,104 bytes allocated.
==5771== For counts of detected errors, rerun with: -v
==5771== All heap blocks were freed -- no leaks are possible.

I really don't understand why it crashes there. Could you try a different compiler?
Tried with gcc 4.0/4.1.x, same crash. I'll try with the msvc compiler later...

Tebasuna told me also that this crash has been occured after rev 490 iirc...I can make a regression test if you want.
tebasuna51
17th May 2007, 08:53
Tebasuna told me also that this crash has been occured after rev 490 iirc...I can make a regression test if you want.
Yes, the problem is between rev475 (work) and rev484 (crash)
DarkAvenger
17th May 2007, 18:28
@kurtnoise13

Please make a debug build (delete cmake cache and run with CFLAGS="-O0 -g3" cmake) and try running with valgrind again. That would be a lot more informative.


Does the MMX routine of that function crash for you? (Run with valgrind, as well, please.) Just hack the cpu_caps_have_sse2 routine to always return 0.

It is interesting that valgrind doesn't mention any problems for me...

@tebasuna51

Does rev 477 crash, as well?


Aaargh, I think I found the bug. Please try current svn.

@Justin

I think next time send release candidates to kurtnoise13, as well. It seems my test sample doesn't catch all bugs. :( I also think we need a quick new release as well. Sorry.
Kurtnoise
17th May 2007, 19:40
Aaargh, I think I found the bug. Please try current svn.
rev 510 works fine now. Many thanks...:)
Kurtnoise
18th May 2007, 08:49
erff...I spoke too fast. It works fine on Linux but not on Windows. :(


edit: it works when I disable sse2/sse3 routines and with the msvc compiler.
DarkAvenger
18th May 2007, 13:38
Does it crash at the same position? Could you try to make a debug build and try to find out where it crashes in the source?
Kurtnoise
18th May 2007, 15:29
Yeah, I suspect the crash at the same position but to be sure which free tool(s) is(are) available on win32 plateform to debug/find out those kind of crashes ?
DarkAvenger
18th May 2007, 15:37
Well, for msvc there whould be winedbg or the vc express ide - but I never tried it with c.

For mingw you can use gdb - which I did:

Anyway I found it crashing with mingw, as well - at a slightlxy different position. This time is was an alignment issue. Please check whether rev 511 fixes this issue.
Kurtnoise
18th May 2007, 16:14
Allright, rev 511 fixes this bug. Many thanks to you...again. :)
DarkAvenger
18th May 2007, 16:21
Thanks for your time in testing/debugging, as well. :)
wisodev
22nd May 2007, 20:42
I was just testing my new Aften builds from svn sources at revision 511 (file: aften-svn-r511-vs2005.zip) (http://sourceforge.net/project/showfiles.php?group_id=183195&package_id=232924) using Visual Studio 2005 and comparing speed with Kurtnoise13 build (http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev511.zip) and Kurtnoise13 Aften build again crushed (my build runs ok) on my system (WinXP SP2 x86, Athlon64 X2 3600+) in the same place as the last bug.

Here is debuger output (VS2005), the yellow arrow shows place where Aften crushed:
http://img61.imageshack.us/img61/4746/crushaftenr511knfc8.th.jpg (http://img61.imageshack.us/my.php?image=crushaftenr511knfc8.jpg)
tebasuna51
23rd May 2007, 00:12
Here work fine both rev511 (Kurtnoise, wisodev).
XP SP1, P4 2400
wisodev
23rd May 2007, 05:18
I found the crush reason!

Kurtnoise13 r511 build does not work on multi core CPUs!

I have 2 core CPU, when I run under VMware machine (WinXP SP2) with enabled one core only then Kurtnoise13 build works.

Maybe there is some issue with multi-threading?

PS. All VS2005 have multi-threading enabled, but the Intel Compiler builds are working with and without MT on my machine.
DarkAvenger
23rd May 2007, 15:48
@wisodev

Could you try compiling aften using cmake and msvc (nmake makefiles) and report back?

I don't have windows on a multi core machine, so I cannot really test.

BTW, I'll be flying off tomorrow for 3.5 weeks and thus won't be able to work on aften for this timespan.

The suggested work-around is then to pass -threads 1 parameter.

Update:

I think I found the place where it crashes, but it is at a different possition:

x86_sse2_exponent.c, line 335. The problem is probably line 325, where I do an aligned load, which is ok, as at line 287 I told the freaking compiler to align the static 2dim array. It seems that crappy mingw gcc compiler kurtnoise13 is using messes this up and doesn't align that array. Grrr.
Quick and dirty solution: Change the aligned load to and unaligned, ie, change _mm_load_si128 to _mm_loadu_si128.
Correct solution: fix the compiler...

I had this problem once at another place. I think gcc is somewhat brokne regarding alignment of multi dim static arrays. Seems I need to work-around this. (No I don't want to change that aligned load, as is sacrifices speed).
Perhaps it is enough to move the array to before the three ints?
wisodev
23rd May 2007, 15:59
@wisodev

Could you try compiling aften using cmake and msvc (nmake makefiles) and report back?

I don't have windows on a multi core machine, so I cannot really test.

BTW, I'll be flying off tomorrow for 3.5 weeks and thus won't be able to work on aften for this timespan.

The suggested work-around is then to pass -threads 1 parameter.


OK. I will do some tests with cmake builds and msvc.
DarkNite
1st June 2007, 09:55
I may have missed something, and apologize if this has already been addressed elsewhere. I see rev512 (http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev512.zip) has been posted, but there's no comments in this thread or a changelog in the the archive.

Has the multicore issue been addressed? I won't be able to test on a multicore win32 machine for a few days. I would gladly test this (or any other) build during the weekend if no one else has free time.
Kurtnoise
1st June 2007, 14:06
I may have missed something, and apologize if this has already been addressed elsewhere. I see rev512 (http://kurtnoise.free.fr/index.php?dir=Aften/&file=aften_rev512.zip) has been posted, but there's no comments in this thread or a changelog in the the archive.
#585 from this thread...
I think I found the place where it crashes, but it is at a different possition:

x86_sse2_exponent.c, line 335. The problem is probably line 325, where I do an aligned load, which is ok, as at line 287 I told the freaking compiler to align the static 2dim array. It seems that crappy mingw gcc compiler kurtnoise13 is using messes this up and doesn't align that array. Grrr.
Quick and dirty solution: Change the aligned load to and unaligned, ie, change _mm_load_si128 to _mm_loadu_si128.
Correct solution: fix the compiler...

I had this problem once at another place. I think gcc is somewhat brokne regarding alignment of multi dim static arrays. Seems I need to work-around this.
Kurtnoise
2nd June 2007, 08:16
How to use Aften with pipeline through ffmpeg ?

this command line doesn't work :
FFmpeg -i input.dts -f s16le - | aften -readtoeof 1 -b 448 - output.ac3

It seems that I get an invalid header according to the stdout :
Input #0, dts, from 'E:\DVDVolume\VIDEO_TS\Audio - DTS - 5ch - DELAY -130ms.DTS
:
Duration: 00:04:01.6, start: 0.000000, bitrate: 767 kb/s
Stream #0.0: Audio: dca, 48000 Hz, 5:1, 768 kb/s
Output #0, s16le, to 'pipe:':
Stream #0.0: Audio: pcm_s16le, 48000 Hz, 5:1, 4608 kb/s
Stream mapping:
Stream #0.0 -> #0.0
Press [q] to stop encoding
invalid RIFF id in wav header
invalid wav file: -readtoeof
size= 138360kB time=246.0 bitrate=4608.0kbits/s
video:0kB audio:138360kB global headers:0kB muxing overhead 0.000000%

Any idea ?
tebasuna51
2nd June 2007, 10:56
How to use Aften with pipeline through ffmpeg ?

It seems that I get an invalid header according to the stdout :

Any idea ?
The command line :
FFmpeg -i input.dts -f s16le - | ...

produce a stereo mix raw data (at least with my ffmpeg version), then there are two problems:

- The stereo mix. I don't know how obtain a decoded multichannel.

- The raw data. How obtain a header from ffmpeg STDOUT? Or, how pass a raw PCM to Aften?
jruggle
2nd June 2007, 16:04
The command line :
FFmpeg -i input.dts -f s16le - | ...

produce a stereo mix raw data (at least with my ffmpeg version), then there are two problems:

- The stereo mix. I don't know how obtain a decoded multichannel.

- The raw data. How obtain a header from ffmpeg STDOUT? Or, how pass a raw PCM to Aften?

Reading the wav files should be fixed now in rev514. Raw input for Aften will be done eventually.
jruggle
2nd June 2007, 16:13
The command line :
FFmpeg -i input.dts -f s16le - | ...

produce a stereo mix raw data (at least with my ffmpeg version), then there are two problems:

- The stereo mix. I don't know how obtain a decoded multichannel.


As far as decoded multichannel, FFmpeg can do it. You have to use:

ffmpeg -i input.dts -ac 6 -acodec pcm_s16le -f wav - | aften - output.ac3

The problem though is that the channel order will be incorrect. FFmpeg does not (yet) do channel reordering. DTS channel order is the same as MPEG-2/4 (C,L,R,Ls,Rs,LFE). I could maybe add another -chmap to Aften for MPEG channel order.
Kurtnoise
2nd June 2007, 16:25
The problem though is that the channel order will be incorrect. FFmpeg does not (yet) do channel reordering. DTS channel order is the same as MPEG-2/4 (C,L,R,Ls,Rs,LFE). I could maybe add another -chorder to Aften for MPEG channel order.
That could be great...:)

:thanks:
jruggle
2nd June 2007, 17:18
The problem though is that the channel order will be incorrect. FFmpeg does not (yet) do channel reordering. DTS channel order is the same as MPEG-2/4 (C,L,R,Ls,Rs,LFE). I could maybe add another -chmap to Aften for MPEG channel order.
This problem is corrected now. You can use "-chmap 2" to remap channels from MPEG order to AC-3 order.
tebasuna51
3rd June 2007, 00:52
As far as decoded multichannel, FFmpeg can do it. You have to use:

ffmpeg -i input.dts -ac 6 -acodec pcm_s16le -f wav - | aften - output.ac3

Maybe is a problem with my ffmpeg version (built on May 13 2006 18:31:30, gcc: 4.1.0 [Sherpya]) or a Windows XP problem, but:

1) With:
ffmpeg -i input.dts -ac 6 -acodec pcm_s16le -f wav output.wav
I obtain a stereo mix of the input.dts

2) With:
ffmpeg -i input.dts -ac 6 -acodec pcm_s16le -f wav - | aften - output.ac3

output.ac3 is not created (even stereo) with messages:
"...
invalid or empty chunk in wav header
invalid wav file: -
..."
jruggle
3rd June 2007, 01:11
Maybe is a problem with my ffmpeg version (built on May 13 2006 18:31:30, gcc: 4.1.0 [Sherpya]) or a Windows XP problem, but:


Wow, that's a really old version. FFmpeg now has its own native DTS decoder with multichannel support. The wav header creation may have changed since then as well...I don't know. A year is a very long time when it comes to FFmpeg development. Try using the latest FFmpeg and let me know how things go.
tebasuna51
3rd June 2007, 11:42
Wow, that's a really old version. FFmpeg now has its own native DTS decoder with multichannel support. The wav header creation may have changed since then as well...I don't know. A year is a very long time when it comes to FFmpeg development. Try using the latest FFmpeg and let me know how things go.
Thanks Justin.
With ffmpeg rev9133 and aften rev521 the command line:
FFmpeg -i input.dts -ac 6 -acodec pcm_s16le -f wav - | aften -chmap 2 - output.ac3
seems work most the times.

Maybe the dts decoder build in ffmpeg is not yet stable, because with the dts extracted (DTSParser v2.0) from this wavdts test (http://www.sr.se/laddahem/MultiKanal/Dts/SURROUNDTEST_011212.zip) crash in my system. This dts is decoded without problems with Tranzcode, NicDTSSource and foo_input_dts.
jruggle
3rd June 2007, 15:40
Maybe the dts decoder build in ffmpeg is not yet stable, because with the dts extracted (DTSParser v2.0) from this wavdts test (http://www.sr.se/laddahem/MultiKanal/Dts/SURROUNDTEST_011212.zip) crash in my system. This dts is decoded without problems with Tranzcode, NicDTSSource and foo_input_dts.
I don't get a crash, but I do get rough audio with lots of artifacts. I get the same from dtsdec (libdca). I'll report the sample to FFmpeg's DTS maintainer.
Kurtnoise
5th June 2007, 06:38
@Tebasuna or somebody else who have a 5.1 surround kit : could you test this sample (http://alkasar.online.fr/Videos_FBHD/Surround Test DTS LFE- FL-SL-SR-FR-C.dts) with the command line above and tell me if you hear the LFE channel...

Thanks.
tebasuna51
5th June 2007, 10:08
@Tebasuna or somebody else who have a 5.1 surround kit : could you test this sample (http://alkasar.online.fr/Videos_FBHD/Surround Test DTS LFE- FL-SL-SR-FR-C.dts) with the command line above and tell me if you hear the LFE channel...

The LFE channel is mute, and is a problem from ffmpeg because:

FFmpeg -i surr_kurt.dts -ac 6 -acodec pcm_s16le -f wav output.wav

also have the LFE mute.

Decoded with Tranzcode, foo_input_ dts, NicAudio the LFE exist with sound at the beginning. The decode with NicAudio also have problems but the LFE is present.