kaldi-developers — Kaldi Developers

Re: [Kaldi-developers] InterpretingTRANS files

[Patrick J. S. <pat...@ld...>]

Perfect – thank you!

From: Daniel Povey [mailto:dp...@gm...]
Sent: Thursday, February 26, 2015 1:14 PM
To: Patrick John Schone
Cc: kal...@li...
Subject: Re: [Kaldi-developers] InterpretingTRANS files

They are archives of matrices, each representing an affine transform of the data for a particular speaker (the last column is the bias term).  You can view as text with:

copy-matrix ark:foo/trans.1 ark,t:- | less

Dan


On Thu, Feb 26, 2015 at 2:13 PM, Patrick John Schone <pat...@ld...<mailto:pat...@ld...>> wrote:
First of all, I must say: KALDI is EXCELLENT!  It has worked well even for a task that it was not designed for – great work!

Second: I have tried to mine the sourceforge pages, but I haven’t been successful in learning how to interpret the “trans” files (such as trans.1, trans.2, etc.).   I’m sure it is a quick little command – can you point me in the right direction?

Thank you!
Patrick Schone


NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/<https://urldefense.proofpoint.com/v2/url?u=http-3A__goparallel.sourceforge.net_&d=AwMFaQ&c=z0adcvxXWKG6LAMN6dVEqQ&r=e4U5TdITe0aZoVv6LKqr-vQSV1EZbg3tLhtzuoAmzrw&m=14m1bEYPrjDXgFhrnD1P6JNgQKK13jSqRO0BWHGqsAU&s=QGB08o6HXs6FQevASdij4yZqPa-9jFFPQL3kAPKtbxU&e=>
_______________________________________________
Kaldi-developers mailing list
Kal...@li...<mailto:Kal...@li...>
https://lists.sourceforge.net/lists/listinfo/kaldi-developers<https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_kaldi-2Ddevelopers&d=AwMFaQ&c=z0adcvxXWKG6LAMN6dVEqQ&r=e4U5TdITe0aZoVv6LKqr-vQSV1EZbg3tLhtzuoAmzrw&m=14m1bEYPrjDXgFhrnD1P6JNgQKK13jSqRO0BWHGqsAU&s=16_KIvQYbzxemqr1PkZ7Jk5S0-rPm-SuKNzGrMyDk6I&e=>



 NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

Re: [Kaldi-developers] InterpretingTRANS files

[Daniel P. <dp...@gm...>]

They are archives of matrices, each representing an affine transform of the
data for a particular speaker (the last column is the bias term).  You can
view as text with:

copy-matrix ark:foo/trans.1 ark,t:- | less

Dan


On Thu, Feb 26, 2015 at 2:13 PM, Patrick John Schone <
pat...@ld...> wrote:

>  First of all, I must say: KALDI is EXCELLENT!  It has worked well even
> for a task that it was not designed for – great work!
>
>
>
> Second: I have tried to mine the sourceforge pages, but I haven’t been
> successful in learning how to interpret the “trans” files (such as trans.1,
> trans.2, etc.).   I’m sure it is a quick little command – can you point me
> in the right direction?
>
>
>
> Thank you!
>
> Patrick Schone
>
>
>
> NOTICE: This email message is for the sole use of the intended
> recipient(s) and may contain confidential and privileged information. Any
> unauthorized review, use, disclosure or distribution is prohibited. If you
> are not the intended recipient, please contact the sender by reply email
> and destroy all copies of the original message.
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>

[Kaldi-developers] InterpretingTRANS files

[Patrick J. S. <pat...@ld...>]

First of all, I must say: KALDI is EXCELLENT!  It has worked well even for a task that it was not designed for - great work!

Second: I have tried to mine the sourceforge pages, but I haven't been successful in learning how to interpret the "trans" files (such as trans.1, trans.2, etc.).   I'm sure it is a quick little command - can you point me in the right direction?

Thank you!
Patrick Schone


 NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.

[Kaldi-developers] Some Kaldi updates

[Daniel P. <dp...@gm...>]

I notice quite a few people are signed up to the kaldi-developers list and
it doesn't get very much traffic, so I thought I should send out some
updates to let people know what's going on.

There has been some email traffic about LSTMs-- a guy called Jiayu Du from
Baidu has been working with Karel and others to implement it in Karel's
setup.  As far as I know it is not yet working better than the baseline- it
seems LSTMs need quite a bit of tuning to get them to work.  Also the
training is pretty slow so we can't train them on a lot of data yet.

In the last few months, in the nnet2 setup we have been using an
architecture we call "multi-splice" where splicing over time happens not
just at the start of the network but at multiple layers.  Typically we
splice 2 frames, but not adjacent ones, and the separation in time
increases for higher layers of the network.  (and the last layer or two
typically don't have splicing).  We modified the training code so it only
evaluates the frames that it needs to evaluate (i.e. to allow gaps in
time).  This is usually giving improvements over our previous (p-norm)
numbers, typically 5% relative or so.  In time we plan to modify all the
nnet2 recipes to use this.

Vijay Peddinti (who was also involved in the multi-splice work) submitted a
Kaldi-based system in the ASPIRE challenge (ASPIRE about reverberant speech
in varying microphone conditions, and Fisher is the only training data you
are allowed to use).  We were just behind the top system (BBN) but our
system was a single system and we believe theirs was a big combination.  We
used a single system, an online-nnet2 system, i.e. with iVectors as input
as well as unadapted 40-dimensional MFCC features.  Vijay trained the
system on Fisher data perturbed with randomly chosen room responses and
room noises that he got from Shinji Watanabe.  He plans to release the
recipe soon.  We trained on 3 copies of the Fisher data (perturbed with
different room responses).  This took only 2 or 3 days for cross-entropy
training, using up to 20 or so GPUs.  We think the reason we did well in
the evaluation is probably some combination of our setup being more
scalable (so we can train on more data in a reasonable time- see
http://arxiv-web3.library.cornell.edu/abs/1410.7455), and maybe Shinji's
"real" room responses being better than the simulation-based ones that we
heard some others used.

While building this system we found some interesting things.  Firstly we
found and fixed a bug whereby the "min-active" parameter was not being
properly enforced by the decoders; this meant that sometimes long
utterances would be decoded as a truncated transcript, due to the decoder
getting stuck in a state which cannot reach the majority of the decoding
graph.  Also we found that the use of iVectors as an adaptation method was
not nearly as robust as we would like.  Firstly, it was not very robust to
variations in volume-- we had to normalize the energy of the test data to
fix this.  Probably this was because we normalized the training-data volume
too carefully; in future we plan to ensure the training data has variations
in volume.
Secondly, we found that it was very important to exclude silence from the
iVector estimation.  This was unexpected, as we included silence in
training time and we normally include it in test time (to avoid the hassle
of voice activity detection).  Perhaps the issue was that the silences we
encountered in test were too different from those we encountered in
training time.  In the end the way we resolved this was to do a first
decoding pass, get the ctm with confidences (lattice-to-ctm-conf), and
filter out words with confidence <1, words with improbably long durations,
mm, mhm, laughter, noise, and so on, and use only what remained for iVector
estimation.  We also found that it was important, for long utterances, to
scale up the prior term in iVector estimation (we added the --max-count
option to some programs to handle this; it's done by scaling down the
counts).
Incidentally, the way we handled segmentation in this system was pretty
brain-dead- we just used overlapping segments of 10 seconds, shifted by 5
seconds each time, and spliced things together at the end, at the ctm
level, using the concept that the transcript will only be disrupted close
to the boundary of each segment and transcripts closer to the middle should
be OK.
We will try to incorporate some of the lessons learned from ASPIRE (e.g.
about the importance of excluding silence for iVector estimation) into the
online-nnet2 setup as soon as we can.

Something else that was added to Kaldi recently (Guoguo Chen did this) is a
compact non-FST format for ARPA language models (search for carpa, or
const-arpa) which enables memory-efficient rescoring of lattices with
un-pruned language models.  You'll see that in some of the scripts, such as
Fisher English, we're already using this.

We have also begun adding pronunciation probabilities to some of the
scripts (work with Guoguo Chen and Hainan Xu).  Here is an excerpt from the
Librispeech training script (run.sh):

 steps/get_prons.sh --cmd "$train_cmd"  data/train_clean_460 data/lang
exp/tri4b_ali_clean_460
 utils/dict_dir_add_pronprobs.sh data/local/dict
 exp/tri4b_ali_clean_460/pron_counts_nowb.txt data/local/dict_pp
 utils/prepare_lang.sh data/local/dict_pp "<SPOKEN_NOISE>"
 data/local/lang_tmp_pp data/lang_pp

So basically after we've built the system a few times, we get the training
alignments, estimate pronunciation probabilities, re-estimate the
dictionary with pronunciation probabilities, and re-build the "lang"
directory to "lang_pp" (with pronunciation probabilities in the L.fst), and
afterwards we use that.  It gives a pretty small improvement, e.g. 0.2% is
typical.  This doesn't require any deep changes in Kaldi, as we basically
always supported pronunciation probabilities, we just hadn't done the
scripting to support them in the standard setups.  (Note: we normalize the
probs so the max prob for each word is 1... we believe this is common, e.g.
IBM does it).

Right now Hainan and Guoguo are working on adding word-specific silence
probabilities, estimated from data; this will be incorporated into the same
workflow as we currently use for estimating pronunciation probabilities so
would be no extra hassle for the user.  It looks like we can generally get
an extra 0.1% to 0.3% from this.  It's not finalized yet, but when it is
we'll start including it in the scripts.

Something that turned out to be important for getting the silence
probabilities, mentioned above, to work is the use of a word insertion
penalty in scoring.  Previously we have mostly avoided the use of word
insertion penalties in Kaldi.  The reason we could get away with this is
that the standard Kaldi scripts use a silence probability of 0.5 (meaning
not-having-a-silence also has a probability of 0.5), and this acts as a
fixed word insertion penalty with a reasonable value.  When we estimate the
probabilities from data, the silence-probability is lower (e.g. 0.1 or 0.2)
so that penalty gets decreased, at least when there is no silence.  Jan
Trmal has added a scoring script steps/score_kaldi.sh which can be used in
cases where you don't need to do sclite scoring, and which supports
searching over insertion penalties and also generates detailed statistics
similar to sclite.  We're using this as the scoring script in the WSJ setup
and will switch over other setups to use it in future.

Other recently added features and options:
  The alignment and training scripts now support a "--careful" option which
should in theory improve alignment quality.  It is a method that is
designed to detect alignment errors where you ate up the words in the
transcript too soon.  It doesn't normally seem to make much of a
difference, but it might make a difference for setups with long segments
and/or errorful transcriptsions.  (but in those scenarios, see
also steps/cleanup/find_bad_utts.sh
and egs/wsj/s5/local/run_segmentation.sh).

The sMBR training (although not yet Karel's nnet1 version, he will add it
soon) supports an option --one-silence-class.  If you notice your sMBR
training is producing too many insertions and too few deletions, you can
try setting this to true and see if it helps; this fixes an asymmetry in
the objective function whereby insertions were not penalized.  This was
important for us in the ASPIRE evaluation.

 We have of course been improving the recipes.  Minhua Wu and Guoguo Chen
and others have been working on a new, improved version of the Switchboard
recipe in egs/swbd/s5c/ (including more consistent data normalization) and
a recipe where we train on Fisher and Switchboard together and test on
eval2000 (egs/fisher_swbd/s5/).  Tony Robinson, Karel and others have been
improving the Tedlium recipe; Tony has released some much-improved language
models that he built for that recipe, and we will soon incorporate these
onto the scripts.

David Snyder has been improving the speaker-id setup, with the help of
Daniel Garcia-Romero (e.g. looking at issues like whitening and length
normalization), and hopes to add sre10 examples soon.  We don't claim to be
in the forefront of speaker-id research (yet), but it's sometimes
convenient to have a "native" Kaldi implementation of speaker-id.

If you contributed something and were not mentioned here, apologies... what
I said above was just what came immediately to my mind, and I'm excluding
things that are more research-y and less immediately relevant to Kaldi
users.

Dan

Re: [Kaldi-developers] Compiling Kaldi on windows

[Jan T. <jt...@gm...>]

Ona last thing that could be tried,  if one really wants to use visual
Studio,  is actually using Intel C/C++,  which has direct integration into
VS,  including the debugger and profiler.  It does not support  integration
into VSExpress,  though  (such is some Microsoft's policy).

BTW,  just for the sake of having it archived in this context: even in
Windows you can use cygwin/mingw to compile kaldi using gcc.

Y.
On Feb 20, 2015 9:32 PM, "Daniel Povey" <dp...@gm...> wrote:

>
> This thing where it can't resolve int32 is a bug in the namespace lookup
> in the compiler, where if a template is evaluated in a different namespace
> from where it was declared, it adds the namespace where it was evaluated
> from to the list of namespaces it searches while instantiating the
> template.  This is against the C++ standard.  I reported this, and many
> other similar issues, to the Visual Studio people when I was at Microsoft
> but they didn't seem that interested in fixing them.  (IIRC I was accused
> of being a "crusader" about minor issues of syntax and the C++ standard).
>
> I'm surprised the compiler crashes at that particular line of
> fstext-utils.h, I had a look and there is nothing particularly complicated
> going on there.  If someone can work out a change that will fix that issue
> I'm open to checking it in, but I'm not sure that I want to personally
> figure it out.
> Dan
>
>
>
> NB: I'm extremely annoyed ATMd m, so I'm sending it as it is, hopefully
>> someone will continue or give me hint, but at this stage it seems that
>> VS2013 cannot be used to compile Kaldi
>> The main reason is the interaction between openfst and kaldi.
>> I tried both OpenFSTWin versions --1.3.1 and 1.4.1
>> Status:
>> During compilation with OpenFSTWin 1.3.1 I was able to compile around 550
>> binaries targets out of approx 600 hundred. There were to minor fixes
>> needed (including <algorithm> where std::min and std::max were used). The
>> major problem looks like to be the way how VS2013 resolves type definition
>> -- there is openfst uint64 (and similar) and there is kaldi::uint64 (and
>> similar). VS2013 however is not able to resolve the correct type -- I get
>> bunch of erros
>>
>> error C2872: 'int32' : ambiguous symbol
>>
>> (Note: these errors can be fixed by using the :: operator, but it's not
>> probably something which would find it's way to kaldi :)
>>
>> Compiling with OpenFST 1.4.1 is even worse -- even that the ambiguity is
>> not fixed in openFST but the VS compiler manages to crash:
>>
>> 1>..\..\..\src\fstext/fstext-utils-inl.h(447): fatal error C1001: An
>> internal error has occurred in the compiler.
>> 1>  (compiler file 'msc1.cpp', line 1325)
>> 1>   To work around this problem, try simplifying or changing the program
>> near the locations listed above.
>> 1>  Please choose the Technical Support command on the Visual C++
>> 1>   Help menu, or open the Technical Support help file for more
>> information
>>
>> BTW -- it's always the fstext-utils-inl.h at the same line, of someone
>> would feel adventurous enough to figure that out. OpenFST 1.4.1 needs
>> C++/11 so I wouldn't even bother with older compilers. :)
>> In the end, I managed to compile around 130 binaries (programs) out of
>> ~600 which the kaldi VS solution has.
>>
>> BTW2: I gave it a shot and tried VS 2015 Beta and it crashes also (on the
>> same file and line)
>> y.
>>
>>
>> PS: I think I was able to get it compile last year with VS 2010
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Kaldi-developers mailing list
>> Kal...@li...
>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>
>>
>

Re: [Kaldi-developers] Compiling Kaldi on windows

[Daniel P. <dp...@gm...>]

This thing where it can't resolve int32 is a bug in the namespace lookup in
the compiler, where if a template is evaluated in a different namespace
from where it was declared, it adds the namespace where it was evaluated
from to the list of namespaces it searches while instantiating the
template.  This is against the C++ standard.  I reported this, and many
other similar issues, to the Visual Studio people when I was at Microsoft
but they didn't seem that interested in fixing them.  (IIRC I was accused
of being a "crusader" about minor issues of syntax and the C++ standard).

I'm surprised the compiler crashes at that particular line of
fstext-utils.h, I had a look and there is nothing particularly complicated
going on there.  If someone can work out a change that will fix that issue
I'm open to checking it in, but I'm not sure that I want to personally
figure it out.
Dan



NB: I'm extremely annoyed ATMd m, so I'm sending it as it is, hopefully
> someone will continue or give me hint, but at this stage it seems that
> VS2013 cannot be used to compile Kaldi
> The main reason is the interaction between openfst and kaldi.
> I tried both OpenFSTWin versions --1.3.1 and 1.4.1
> Status:
> During compilation with OpenFSTWin 1.3.1 I was able to compile around 550
> binaries targets out of approx 600 hundred. There were to minor fixes
> needed (including <algorithm> where std::min and std::max were used). The
> major problem looks like to be the way how VS2013 resolves type definition
> -- there is openfst uint64 (and similar) and there is kaldi::uint64 (and
> similar). VS2013 however is not able to resolve the correct type -- I get
> bunch of erros
>
> error C2872: 'int32' : ambiguous symbol
>
> (Note: these errors can be fixed by using the :: operator, but it's not
> probably something which would find it's way to kaldi :)
>
> Compiling with OpenFST 1.4.1 is even worse -- even that the ambiguity is
> not fixed in openFST but the VS compiler manages to crash:
>
> 1>..\..\..\src\fstext/fstext-utils-inl.h(447): fatal error C1001: An
> internal error has occurred in the compiler.
> 1>  (compiler file 'msc1.cpp', line 1325)
> 1>   To work around this problem, try simplifying or changing the program
> near the locations listed above.
> 1>  Please choose the Technical Support command on the Visual C++
> 1>   Help menu, or open the Technical Support help file for more
> information
>
> BTW -- it's always the fstext-utils-inl.h at the same line, of someone
> would feel adventurous enough to figure that out. OpenFST 1.4.1 needs
> C++/11 so I wouldn't even bother with older compilers. :)
> In the end, I managed to compile around 130 binaries (programs) out of
> ~600 which the kaldi VS solution has.
>
> BTW2: I gave it a shot and tried VS 2015 Beta and it crashes also (on the
> same file and line)
> y.
>
>
> PS: I think I was able to get it compile last year with VS 2010
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>

[Kaldi-developers] Compiling Kaldi on windows

[Jan T. <jt...@gm...>]

NB: I'm extremely annoyed ATM, so I'm sending it as it is, hopefully
someone will continue or give me hint, but at this stage it seems that
VS2013 cannot be used to compile Kaldi
The main reason is the interaction between openfst and kaldi.
I tried both OpenFSTWin versions --1.3.1 and 1.4.1
Status:
During compilation with OpenFSTWin 1.3.1 I was able to compile around 550
binaries targets out of approx 600 hundred. There were to minor fixes
needed (including <algorithm> where std::min and std::max were used). The
major problem looks like to be the way how VS2013 resolves type definition
-- there is openfst uint64 (and similar) and there is kaldi::uint64 (and
similar). VS2013 however is not able to resolve the correct type -- I get
bunch of erros

error C2872: 'int32' : ambiguous symbol

(Note: these errors can be fixed by using the :: operator, but it's not
probably something which would find it's way to kaldi :)

Compiling with OpenFST 1.4.1 is even worse -- even that the ambiguity is
not fixed in openFST but the VS compiler manages to crash:

1>..\..\..\src\fstext/fstext-utils-inl.h(447): fatal error C1001: An
internal error has occurred in the compiler.
1>  (compiler file 'msc1.cpp', line 1325)
1>   To work around this problem, try simplifying or changing the program
near the locations listed above.
1>  Please choose the Technical Support command on the Visual C++
1>   Help menu, or open the Technical Support help file for more information

BTW -- it's always the fstext-utils-inl.h at the same line, of someone
would feel adventurous enough to figure that out. OpenFST 1.4.1 needs
C++/11 so I wouldn't even bother with older compilers. :)
In the end, I managed to compile around 130 binaries (programs) out of ~600
which the kaldi VS solution has.

BTW2: I gave it a shot and tried VS 2015 Beta and it crashes also (on the
same file and line)
y.


PS: I think I was able to get it compile last year with VS 2010

Re: [Kaldi-developers] Windows Visual Studio build attempt and patches

[Michael F. <mic...@sr...>]

Sounds good. Thank you.

I will keep you posted with additional updates.

Mike

On 2/19/2015 12:58 PM, Daniel Povey wrote:
> I have committed fixes for these issues (I fixed the 
> comment-in-Makefile issue by changing the .pl script).  I hope the 
> perl script still works, I changed the newline style to UNIX.
> Let us know if you have further fixes.
> Dan
>
>
> On Thu, Feb 19, 2015 at 1:51 PM, Michael Frandsen 
> <mic...@sr... <mailto:mic...@sr...>> wrote:
>
>     Potential issues:
>     - Looks like openfst builds 32 bit (not 64) and uses VS 2010
>     - Kaldi will target 64 bit and uses VS 2012
>     (not sure if this is an issue yet)
>
>     Patches:
>
>     (1) The perl script that generates a VS 2012 project file from
>     Makefiles
>     tries to include a non-present file due to the perl script not
>     interpreting # as a comment. Patch:
>
>     $ svn diff src/matrix/Makefile
>     Index: src/matrix/Makefile
>     ===================================================================
>     --- src/matrix/Makefile (revision 4904)
>     +++ src/matrix/Makefile (working copy)
>     @@ -10,7 +10,8 @@
>
>       # you can uncomment matrix-lib-speed-test if you want to do the
>     speed
>     tests.
>
>     -TESTFILES = matrix-lib-test kaldi-gpsr-test #matrix-lib-speed-test
>     +#matrix-lib-speed-test
>     +TESTFILES = matrix-lib-test kaldi-gpsr-test
>
>       OBJFILES = kaldi-matrix.o kaldi-vector.o packed-matrix.o sp-matrix.o
>     tp-matrix.o \
>                  matrix-functions.o qr.o srfft.o kaldi-gpsr.o
>     compressed-matrix.o \
>
>
>     (2) generate_solution.pl <http://generate_solution.pl> has a typo.
>     Patch:
>
>     $ svn diff windows/generate_solution.pl <http://generate_solution.pl>
>     Index: windows/generate_solution.pl <http://generate_solution.pl>
>     ===================================================================
>     --- windows/generate_solution.pl <http://generate_solution.pl>    
>       (revision 4904)
>     +++ windows/generate_solution.pl <http://generate_solution.pl>    
>       (working copy)
>     @@ -394,7 +394,7 @@
>         </PropertyGroup>
>         <PropertyGroup
>     Condition=\"'\$(Configuration)|\$(Platform)'=='Release|Win32'\"
>     Label=\"Configuration\">
>           <ConfigurationType>" . $conftype . "</ConfigurationType>
>     -    <CharacterSet>Unicode</CharacterSeti>
>     +    <CharacterSet>Unicode</CharacterSet>
>           <PlatformToolset>v110</PlatformToolset>
>     <WholeProgramOptimization>true</WholeProgramOptimization>
>         </PropertyGroup>
>
>
>     Mike
>
>     ---
>     This email has been checked for viruses by Avast antivirus software.
>     http://www.avast.com
>
>
>     ------------------------------------------------------------------------------
>     Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>     from Actuate! Instantly Supercharge Your Business Reports and
>     Dashboards
>     with Interactivity, Sharing, Native Excel Exports, App Integration
>     & more
>     Get technology previously reserved for billion-dollar
>     corporations, FREE
>     http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Kaldi-developers mailing list
>     Kal...@li...
>     <mailto:Kal...@li...>
>     https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>



---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: [Kaldi-developers] Windows Visual Studio build attempt and patches

[Daniel P. <dp...@gm...>]

I have committed fixes for these issues (I fixed the comment-in-Makefile
issue by changing the .pl script).  I hope the perl script still works, I
changed the newline style to UNIX.
Let us know if you have further fixes.
Dan


On Thu, Feb 19, 2015 at 1:51 PM, Michael Frandsen <mic...@sr...>
wrote:

> Potential issues:
> - Looks like openfst builds 32 bit (not 64) and uses VS 2010
> - Kaldi will target 64 bit and uses VS 2012
> (not sure if this is an issue yet)
>
> Patches:
>
> (1) The perl script that generates a VS 2012 project file from Makefiles
> tries to include a non-present file due to the perl script not
> interpreting # as a comment. Patch:
>
> $ svn diff src/matrix/Makefile
> Index: src/matrix/Makefile
> ===================================================================
> --- src/matrix/Makefile (revision 4904)
> +++ src/matrix/Makefile (working copy)
> @@ -10,7 +10,8 @@
>
>   # you can uncomment matrix-lib-speed-test if you want to do the speed
> tests.
>
> -TESTFILES = matrix-lib-test kaldi-gpsr-test #matrix-lib-speed-test
> +#matrix-lib-speed-test
> +TESTFILES = matrix-lib-test kaldi-gpsr-test
>
>   OBJFILES = kaldi-matrix.o kaldi-vector.o packed-matrix.o sp-matrix.o
> tp-matrix.o \
>              matrix-functions.o qr.o srfft.o kaldi-gpsr.o
> compressed-matrix.o \
>
>
> (2) generate_solution.pl has a typo. Patch:
>
> $ svn diff windows/generate_solution.pl
> Index: windows/generate_solution.pl
> ===================================================================
> --- windows/generate_solution.pl        (revision 4904)
> +++ windows/generate_solution.pl        (working copy)
> @@ -394,7 +394,7 @@
>     </PropertyGroup>
>     <PropertyGroup
> Condition=\"'\$(Configuration)|\$(Platform)'=='Release|Win32'\"
> Label=\"Configuration\">
>       <ConfigurationType>" . $conftype . "</ConfigurationType>
> -    <CharacterSet>Unicode</CharacterSeti>
> +    <CharacterSet>Unicode</CharacterSet>
>       <PlatformToolset>v110</PlatformToolset>
> <WholeProgramOptimization>true</WholeProgramOptimization>
>     </PropertyGroup>
>
>
> Mike
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> http://www.avast.com
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>

[Kaldi-developers] Windows Visual Studio build attempt and patches

[Michael F. <mic...@sr...>]

Potential issues:
- Looks like openfst builds 32 bit (not 64) and uses VS 2010
- Kaldi will target 64 bit and uses VS 2012
(not sure if this is an issue yet)

Patches:

(1) The perl script that generates a VS 2012 project file from Makefiles 
tries to include a non-present file due to the perl script not 
interpreting # as a comment. Patch:

$ svn diff src/matrix/Makefile
Index: src/matrix/Makefile
===================================================================
--- src/matrix/Makefile (revision 4904)
+++ src/matrix/Makefile (working copy)
@@ -10,7 +10,8 @@

  # you can uncomment matrix-lib-speed-test if you want to do the speed 
tests.

-TESTFILES = matrix-lib-test kaldi-gpsr-test #matrix-lib-speed-test
+#matrix-lib-speed-test
+TESTFILES = matrix-lib-test kaldi-gpsr-test

  OBJFILES = kaldi-matrix.o kaldi-vector.o packed-matrix.o sp-matrix.o 
tp-matrix.o \
             matrix-functions.o qr.o srfft.o kaldi-gpsr.o 
compressed-matrix.o \


(2) generate_solution.pl has a typo. Patch:

$ svn diff windows/generate_solution.pl
Index: windows/generate_solution.pl
===================================================================
--- windows/generate_solution.pl        (revision 4904)
+++ windows/generate_solution.pl        (working copy)
@@ -394,7 +394,7 @@
    </PropertyGroup>
    <PropertyGroup 
Condition=\"'\$(Configuration)|\$(Platform)'=='Release|Win32'\" 
Label=\"Configuration\">
      <ConfigurationType>" . $conftype . "</ConfigurationType>
-    <CharacterSet>Unicode</CharacterSeti>
+    <CharacterSet>Unicode</CharacterSet>
      <PlatformToolset>v110</PlatformToolset>
<WholeProgramOptimization>true</WholeProgramOptimization>
    </PropertyGroup>


Mike

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Re: [Kaldi-developers] Bug in Resource Management script?

[Daniel P. <dp...@gm...>]

I just added a sleep statement which should resolve this.
There was another call, later on, to that script which also had a sleep
statement after it.
Likely because the >(...) syntax creates a pipe for writing to, and
possibly bash doesn't wait for the program created by that pipe to finish
executing before it continues.
Dan


On Wed, Feb 18, 2015 at 11:30 PM, <Dan...@pa...> wrote:

>   Seems unlikely, but when I run rm_data_prep.sh, the data/train
> directory gets the right files, except that “text” is correct and the
> others are empty.  When I put a “sleep 1” or “ls –l data/train” after the
> first call to “local/make_trans.pl”, everything works great.  It’s very
> repeatable on this particular machine.
>
>
>
> I’m running bash on CentOS 6.6 on a single box (no cluster, no VM).  The
> machine has a 3.1 GHz x86_64 processor with 4 cores and 16 GB of memory.
>
>
>
> Dan
>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>

[Kaldi-developers] Bug in Resource Management script?

[<Dan...@pa...>]

Seems unlikely, but when I run rm_data_prep.sh, the data/train directory gets the right files, except that “text” is correct and the others are empty.  When I put a “sleep 1” or “ls –l data/train” after the first call to “local/make_trans.pl”, everything works great.  It’s very repeatable on this particular machine.

I’m running bash on CentOS 6.6 on a single box (no cluster, no VM).  The machine has a 3.1 GHz x86_64 processor with 4 cores and 16 GB of memory.

Dan

Re: [Kaldi-developers] python wrappers for Kaldi

[Sean T. <se...@se...>]

Dan, et al. --

My most common use is for doing graphics and reporting on extracted data.
Plotting voicing and pitch on top of a spectrogram using matplotlib is an
example.

I'm also interposing python code between stages of standard kaldi pipelines
for monitoring, while maintaining pipeline parallelism (not having to land
each stream of data). I could use copy-matrix, I suppose, but the pipelines
are complex enough already :-)

-- Sean

On Mon, Feb 16, 2015 at 2:31 PM, Daniel Povey <dp...@gm...> wrote:

> Sean, can you give us some general idea of how you were using the kaldi_io
> package?
> Dan
>
>
> On Mon, Feb 16, 2015 at 10:29 AM, Jan Trmal <af...@ce...> wrote:
>
>> Personally, if we were to include wrappers directly into kaldi, I'd
>> prefer SWIG as the wrapper generator. I worked to some extent with ctypes,
>> boost::python and swig and all are usable and "just fine" for python.
>> The concern I have is however, if this is going to be put into kaldi
>> trunk and we want it to be really useful, then someone will have to
>> maintain it, take the responsibility for it and make it in sync with the
>> C/C++ code, which given the rate of kaldi development will need more than
>> negligible commitment. Yes we can argue that "the community will keep it
>> updated" but frankly, I didn't see any successful project working without
>> someone committing to do even the ugly/boring/maintenance work on regular
>> basis. And for that a wider user base might be more stimulating in the
>> sense that the maintainer would see the wrappers are used (which would
>> yield more feedback/bugreports). Which means (at least to me) that more
>> languages should be supported -- at least python, perl, java...  From all
>> those wrapper generators, only SWIG can do that -- i.e. after writing one
>> interface file, it can generate wrappers for those langs (and some other as
>> well).
>>
>> Just my two cents..
>> y.
>>
>>
>> On Mon, Feb 16, 2015 at 8:52 AM, Sean True <se...@se...>
>> wrote:
>>
>>> I wanted to bring up the integration of the very useful kaldi_io package
>>> that Jan Chorowski made available in December. Is there any consensus on
>>> whether to provide this code as (probably an optional) part of the Kaldi
>>> release? I understand that Boost-Python is a relatively heavy requirement,
>>> but it is easily available on OSX and Linux.
>>>
>>> I continue to wrap the executables themselves in python functional
>>> wrappers, which has made the integration with other software easier, and
>>> contributes to pipeline testability and robustness.
>>>
>>> -- Sean
>>>
>>> On Fri, Dec 26, 2014 at 11:02 AM, Sean True <se...@se...>
>>> wrote:
>>>
>>>> I wanted to echo Ondrej's comment about preferring Python to bash/perl
>>>> for scripting. Python wrappers for the command line utilities are useful
>>>> ... I've spent a few hours systematically wrapping them, parsing the output
>>>> of the --help command as a guide to functionality.
>>>>
>>>> This gives wrappers of the general form:
>>>>
>>>> def acc_lda(transition_gmm_model, features_rspecifier,
>>>> posteriors_rspecifier, lda_acc_out, *args, **kwargs):
>>>>     """Accumulate LDA statistics based on pdf-ids.
>>>>     Executable usage:  acc-lda [options] <transition-gmm/model>
>>>> <features-rspecifier> <posteriors-rspecifier> <lda-acc-out>
>>>>     Options:
>>>>     binary:  Write accumulators in binary mode.  (bool,true)
>>>>     rand_prune:  Randomized pruning threshold for posteriors
>>>>  (float,0)"""
>>>>     cmd = sh.Command(kaldi_path("src/bin/acc-lda"))
>>>>     option_defs = {'binary': ('binary', 'bool', 'true'), 'help':
>>>> ('help', 'bool', 'false'), 'rand_prune': ('rand-prune', 'float', '0'),
>>>> 'config': ('config', 'string', ''), 'print_args': ('print-args', 'bool',
>>>> 'true'), 'verbose': ('verbose', 'int', '0')}
>>>>     myOptions = create_options(option_defs, kwargs)
>>>>     myArgs = [transition_gmm_model, features_rspecifier,
>>>> posteriors_rspecifier, lda_acc_out]+list(args)
>>>>     return cmd (myOptions + myArgs)
>>>>
>>>> There are some refinements that could be added (*args does not make
>>>> sense for this function).
>>>> Because of the rather elegant Python sh package (
>>>> https://pypi.python.org/pypi/sh) these functions will create pipelines
>>>> if composed:
>>>>
>>>> >>> from sh import ls, wc
>>>>
>>>> >>> wc(ls("."))
>>>>
>>>>        8      23     222
>>>>
>>>> There are a few places where constructing from help output is not
>>>> straightforward (for instance, fstrand --help does
>>>> not do the expected thing).
>>>>
>>>> -- Sean
>>>>
>>>> On Fri, Dec 19, 2014 at 6:48 AM, Ondrej Platek <ond...@gm...>
>>>> wrote:
>>>> >
>>>> > Hi Matthew,
>>>> >
>>>> > I made some subjective comments below.
>>>> >
>>>> > PS: Note that I like the proposed wrappers, but I am not sure how
>>>> boost::python is easy to install on all supported platforms.
>>>> >
>>>> > On Fri, Dec 19, 2014 at 9:30 AM, Matthew Aylett <
>>>> mat...@gm...> wrote:
>>>> >>
>>>> >> Hi
>>>> >>
>>>> >> Apologies, I've been snowed under here.
>>>> >>
>>>> >> I haven' had a chance to look over your work. I also don't have any
>>>> views on the 'right' way to do it. My thoughts on this are in a previous
>>>> thread. See subject "Using SWIG to wrap kaldi for python" where I discussed
>>>> this with ondrej platek and
>>>> >> Vassil Panayotov.
>>>> >>
>>>> >> In the idlak branch there is an example of python wrappers that I
>>>> put together some time ago. These are based on SWIG. In the end I didn't
>>>> need this at this stage because in the build system command line
>>>> executables work very well. Its in run time wrappers are very useful. The
>>>> advantage with SWIG is that the much of the same work will also contribute
>>>> to C#, Java, Perl wrappers as well. In my experience the most important
>>>> were Java wrappers to help produce a library for Android. I have no
>>>> experience with C# and moved to Python from Perl so only use Perl in legacy
>>>> code ;-).
>>>> >>
>>>> >> So some questions to consider:
>>>> >>
>>>> >> 1. Why is python wrapping required for training. using sys.Process
>>>> to run command lines, structured output directories etc mirrors the current
>>>> Perl recipes, what is the added benefit in this case?
>>>> >
>>>> > Well bash and Perl is the current scripting language for Kaldi. For
>>>> example I prefer to use Python instead of both of them.
>>>> >
>>>> >>
>>>> >> 2. If its for run time decoding shouldn't we create a cross platfom
>>>>  C API? Perhaps things have changed but C++ APIs were never cross compiler
>>>> compatible in the past so you couldn't do stuff like compile using gnu and
>>>> link in MSN. With a C interface you can distribute libraries. But I am
>>>> possibly out of date on this.
>>>> >
>>>> > Well, I tried that and I gave it up since Kaldi nicely uses OpenFST
>>>> and I was not able to wrap OpenFST with just plain C (It may be possible).
>>>> > I used Cython and pyfst mainly because pyfst solved for me wrapping
>>>> up OpenFST and I am really glad that 99% of wrapping OpenFST templates was
>>>> carried out by somebody else (Victor Chahuneau).
>>>> >>
>>>> >>
>>>> >> 3. If 2 is correct shouldn't we define our API and wrap that?
>>>> Producing a formal list of functionality that should be exposed to things
>>>> like client and server applications?
>>>> >>
>>>> >>
>>>> >> I would encourage some care here. Unconstrained wrapping can lead to
>>>> systems which HAVE to use the scripting language (We can already see how
>>>> difficult it is to move away from the Perl scripting if you wish to). Also
>>>> never, never, never reverse wrap (i.e. call python from within C++), yes it
>>>> can be done but that way lays madness.
>>>> >>
>>>> >> v best
>>>> >>
>>>> >> Matthew
>>>> >>
>>>> >>
>>>> >> On Thu, Dec 18, 2014 at 11:37 PM, Daniel Povey <dp...@gm...>
>>>> wrote:
>>>> >>>
>>>> >>> Jan-
>>>> >>> I haven't seen any objections to your setup.  I'd say we should plan
>>>> >>> to include it in Kaldi at some point (e.g. within the next few
>>>> >>> months), but in the meantime hopefully you can continue to work on
>>>> it,
>>>> >>> and maybe come up with some other examples of how it's useful to do
>>>> >>> the interfacing with Python- e.g. some kind of application level or
>>>> >>> service-level thing?
>>>> >>> Dan
>>>> >>>
>>>> >>>
>>>> >>> On Sat, Dec 13, 2014 at 4:01 PM, Yajie Miao <yaj...@gm...>
>>>> wrote:
>>>> >>> > Hi Jan,
>>>> >>> > This is very nice work! In our PDNN toolkit, we also have simple
>>>> python
>>>> >>> > wrappers to read and write Kaldi features, mainly for DNN
>>>> training. Your
>>>> >>> > implementation looks like a more comprehensive version.
>>>> >>> >
>>>> >>> > Do you have the functions/commands to do feature splicing? I ask
>>>> this
>>>> >>> > because we found doing splicing on the fly with Python highly
>>>> expensive.
>>>> >>> > That's why we still stick to PFiles instead of Kaldi features
>>>> (.scp .ark)
>>>> >>> > for DNN triaining. I am very  interested to know the efficiency
>>>> of your
>>>> >>> > splicing implementation.
>>>> >>> >
>>>> >>> > Thanks,
>>>> >>> > Yajie
>>>> >>> >
>>>> >>> > On Sat, Dec 13, 2014 at 5:59 PM, Daniel Povey <dp...@gm...>
>>>> wrote:
>>>> >>> >>
>>>> >>> >> OK, thanks.
>>>> >>> >> cc'ing Yajie in case he wants to comment.
>>>> >>> >> Dan
>>>> >>> >>
>>>> >>> >>
>>>> >>> >> On Sat, Dec 13, 2014 at 2:31 PM, Jan Chorowski <
>>>> jan...@gm...>
>>>> >>> >> wrote:
>>>> >>> >> > Hi All,
>>>> >>> >> >
>>>> >>> >> > the wrapper is built during Kaldi compilation. I build it
>>>> using provided
>>>> >>> >> > Makefile. The build depends on:
>>>> >>> >> > 1. Python and numpy (by default it queries the python
>>>> interpreter found
>>>> >>> >> > on
>>>> >>> >> > the path for header file location)
>>>> >>> >> > 2. Boost with Boost::Python library. It is quite heavy to
>>>> build, but
>>>> >>> >> > most
>>>> >>> >> > Linux distributions ship it. Boost python doesn't require any
>>>> code
>>>> >>> >> > generation steps, the wrapper is defined in a normal c++ code
>>>> file.
>>>> >>> >> >
>>>> >>> >> > During build Python and Boost libraries and Kaldi object files
>>>> are
>>>> >>> >> > linked
>>>> >>> >> > into a CPython extention module,
>>>> kaldi/src/python/kaldi_io_internal.so.
>>>> >>> >> > It
>>>> >>> >> > works with both static and shared Kaldi builds. Further usage
>>>> requires
>>>> >>> >> > that
>>>> >>> >> > python finds kaldi_io.py and kaldi_io_internal.so on the
>>>> PYTHONPATH - it
>>>> >>> >> > can
>>>> >>> >> > be for example added to the PYTHONPATH variable in the path.sh
>>>> script of
>>>> >>> >> > a
>>>> >>> >> > recipe.
>>>> >>> >> >
>>>> >>> >> > Jan
>>>> >>> >> >
>>>> >>> >> >
>>>> >>> >> > On 12/13/2014 3:33 PM, Daniel Povey wrote:
>>>> >>> >> >>
>>>> >>> >> >> Also, Jan- could you send us an email explaining how this
>>>> works-
>>>> >>> >> >>    How does Python "see" the C++ headers?  Do you have to
>>>> invoke some
>>>> >>> >> >> special program, like swig?  Do you have to write some
>>>> special kind of
>>>> >>> >> >> header that shows how the C++ objects are to be interpreted
>>>> by python?
>>>> >>> >> >>   A brief example would be helpful, if so.
>>>> >>> >> >>    How is the resulting program linked, if at all?  If you
>>>> require
>>>> >>> >> >> functions C++ libraries, are these obtained from the .a or
>>>> .so files
>>>> >>> >> >> at runtime, or compiled into some kind of executable-like
>>>> blob at
>>>> >>> >> >> compile time?  Does your framework require that Kaldi be
>>>> compiled
>>>> >>> >> >> using dynamic (.so) libraries?
>>>> >>> >> >>
>>>> >>> >> >> Dan
>>>> >>> >> >>
>>>> >>> >> >>
>>>> >>> >> >> On Sat, Dec 13, 2014 at 12:04 PM, Jan Chorowski
>>>> >>> >> >> <jan...@gm...>
>>>> >>> >> >> wrote:
>>>> >>> >> >>>
>>>> >>> >> >>> Hello Dan,
>>>> >>> >> >>>
>>>> >>> >> >>> thank you for the comments. I tried to make it in the Kaldi
>>>> spirit,
>>>> >>> >> >>> consistency is important. Of course, the scripts can be
>>>> removed and
>>>> >>> >> >>> replaced
>>>> >>> >> >>> with some more useful examples. I don't have too much
>>>> experience with
>>>> >>> >> >>> bridging Python to C++, so any critique on the wrappers and
>>>> the
>>>> >>> >> >>> approach
>>>> >>> >> >>> taken is welcome.
>>>> >>> >> >>>
>>>> >>> >> >>> Jan
>>>> >>> >> >>>
>>>> >>> >> >>>
>>>> >>> >> >>> On 12/13/2014 2:55 PM, Daniel Povey wrote:
>>>> >>> >> >>>>
>>>> >>> >> >>>> Hi all.
>>>> >>> >> >>>>   From a first look, it does look very impressive, and
>>>> nicely
>>>> >>> >> >>>> documented.
>>>> >>> >> >>>> I would appreciate it if people on the list who have Python
>>>> >>> >> >>>> experience
>>>> >>> >> >>>> would comment on this- you can either reply to this thread,
>>>> or to me.
>>>> >>> >> >>>> I don't know if this has been done in the "natural" way, or
>>>> if there
>>>> >>> >> >>>> is some reason why people in the future will say, "why did
>>>> you do it
>>>> >>> >> >>>> this way, you should have done XXX".
>>>> >>> >> >>>>
>>>> >>> >> >>>> Jan:
>>>> >>> >> >>>> in the scripts/ directory you seem to have some examples of
>>>> how you
>>>> >>> >> >>>> can create python programs that behave very much like Kaldi
>>>> >>> >> >>>> command-line programs, using your framework.  This is very
>>>> useful.
>>>> >>> >> >>>> However, the programs
>>>> >>> >> >>>>    apply-global-cmvn.py
>>>> >>> >> >>>>    compute-global-cmvn-stats.py
>>>> >>> >> >>>> are perhaps a little confusing because they provide the same
>>>> >>> >> >>>> functionality that you could get with "compute-cmvn-stats ->
>>>> >>> >> >>>> matrix-sum" and "apply-cmvn" on the output of that command;
>>>> and they
>>>> >>> >> >>>> do so using different formats for the CMVN information.  I
>>>> know the
>>>> >>> >> >>>> format of storing the CMVN stats in a two-row matrix is
>>>> perhaps not
>>>> >>> >> >>>> perfectly ideal, but it's a standard within Kaldi and it
>>>> would be
>>>> >>> >> >>>> confusing to deviate from that standard.
>>>> >>> >> >>>> Of course, this is a very minor issue that doesn't affect
>>>> the
>>>> >>> >> >>>> validity
>>>> >>> >> >>>> of the framework as a whole.  I am just pointing this out;
>>>> the main
>>>> >>> >> >>>> discussion should be about the framework and whether people
>>>> feel it's
>>>> >>> >> >>>> the "right" way to do this.
>>>> >>> >> >>>>
>>>> >>> >> >>>> Dan
>>>> >>> >> >>>>
>>>> >>> >> >>>> On Sat, Dec 13, 2014 at 6:28 AM, Jan Chorowski
>>>> >>> >> >>>> <jan...@gm...>
>>>> >>> >> >>>> wrote:
>>>> >>> >> >>>>>
>>>> >>> >> >>>>> Hi all!
>>>> >>> >> >>>>>
>>>> >>> >> >>>>> I've written wrappers to access Kaldi data files from
>>>> within Python
>>>> >>> >> >>>>> using boost::python (the code is on github
>>>> >>> >> >>>>>
>>>> https://github.com/janchorowski/kaldi-git/tree/python/src/python).
>>>> >>> >> >>>>> If
>>>> >>> >> >>>>> you think this would be an interesting addition please
>>>> instruct me
>>>> >>> >> >>>>> how
>>>> >>> >> >>>>> to contribute.
>>>> >>> >> >>>>>
>>>> >>> >> >>>>> Best Regards,
>>>> >>> >> >>>>> Jan Chorowski
>>>> >>> >> >>>>>
>>>> >>> >> >>>>>
>>>> >>> >> >>>>>
>>>> >>> >> >>>>>
>>>> >>> >> >>>>>
>>>> >>> >> >>>>>
>>>> ------------------------------------------------------------------------------
>>>> >>> >> >>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT
>>>> Server
>>>> >>> >> >>>>> from Actuate! Instantly Supercharge Your Business Reports
>>>> and
>>>> >>> >> >>>>> Dashboards
>>>> >>> >> >>>>> with Interactivity, Sharing, Native Excel Exports, App
>>>> Integration &
>>>> >>> >> >>>>> more
>>>> >>> >> >>>>> Get technology previously reserved for billion-dollar
>>>> corporations,
>>>> >>> >> >>>>> FREE
>>>> >>> >> >>>>>
>>>> >>> >> >>>>>
>>>> >>> >> >>>>>
>>>> >>> >> >>>>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>> >>> >> >>>>> _______________________________________________
>>>> >>> >> >>>>> Kaldi-developers mailing list
>>>> >>> >> >>>>> Kal...@li...
>>>> >>> >> >>>>>
>>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>>> >>> >> >>>
>>>> >>> >> >>>
>>>> >>> >> >
>>>> >>> >
>>>> >>> >
>>>> >>>
>>>> >>>
>>>> ------------------------------------------------------------------------------
>>>> >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> >>> from Actuate! Instantly Supercharge Your Business Reports and
>>>> Dashboards
>>>> >>> with Interactivity, Sharing, Native Excel Exports, App Integration
>>>> & more
>>>> >>> Get technology previously reserved for billion-dollar corporations,
>>>> FREE
>>>> >>>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>> >>> _______________________________________________
>>>> >>> Kaldi-developers mailing list
>>>> >>> Kal...@li...
>>>> >>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>>> >>
>>>> >>
>>>> >>
>>>> ------------------------------------------------------------------------------
>>>> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> >> from Actuate! Instantly Supercharge Your Business Reports and
>>>> Dashboards
>>>> >> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>> more
>>>> >> Get technology previously reserved for billion-dollar corporations,
>>>> FREE
>>>> >>
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>> >> _______________________________________________
>>>> >> Kaldi-developers mailing list
>>>> >> Kal...@li...
>>>> >> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>>> >>
>>>> >
>>>> >
>>>> > --
>>>> > Ondřej Plátek, +420 737 758 650, skype:ondrejplatek,
>>>> ond...@gm...
>>>> >
>>>> >
>>>> ------------------------------------------------------------------------------
>>>> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>>> > from Actuate! Instantly Supercharge Your Business Reports and
>>>> Dashboards
>>>> > with Interactivity, Sharing, Native Excel Exports, App Integration &
>>>> more
>>>> > Get technology previously reserved for billion-dollar corporations,
>>>> FREE
>>>> >
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>>> > _______________________________________________
>>>> > Kaldi-developers mailing list
>>>> > Kal...@li...
>>>> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>>> >
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>>> Get technology previously reserved for billion-dollar corporations, FREE
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Kaldi-developers mailing list
>>> Kal...@li...
>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Kaldi-developers mailing list
>> Kal...@li...
>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>
>>
>

Re: [Kaldi-developers] python wrappers for Kaldi

[Daniel P. <dp...@gm...>]

Sean, can you give us some general idea of how you were using the kaldi_io
package?
Dan


On Mon, Feb 16, 2015 at 10:29 AM, Jan Trmal <af...@ce...> wrote:

> Personally, if we were to include wrappers directly into kaldi, I'd prefer
> SWIG as the wrapper generator. I worked to some extent with ctypes,
> boost::python and swig and all are usable and "just fine" for python.
> The concern I have is however, if this is going to be put into kaldi trunk
> and we want it to be really useful, then someone will have to maintain it,
> take the responsibility for it and make it in sync with the C/C++ code,
> which given the rate of kaldi development will need more than negligible
> commitment. Yes we can argue that "the community will keep it updated" but
> frankly, I didn't see any successful project working without someone
> committing to do even the ugly/boring/maintenance work on regular basis.
> And for that a wider user base might be more stimulating in the sense that
> the maintainer would see the wrappers are used (which would yield more
> feedback/bugreports). Which means (at least to me) that more languages
> should be supported -- at least python, perl, java...  From all those
> wrapper generators, only SWIG can do that -- i.e. after writing one
> interface file, it can generate wrappers for those langs (and some other as
> well).
>
> Just my two cents..
> y.
>
>
> On Mon, Feb 16, 2015 at 8:52 AM, Sean True <se...@se...>
> wrote:
>
>> I wanted to bring up the integration of the very useful kaldi_io package
>> that Jan Chorowski made available in December. Is there any consensus on
>> whether to provide this code as (probably an optional) part of the Kaldi
>> release? I understand that Boost-Python is a relatively heavy requirement,
>> but it is easily available on OSX and Linux.
>>
>> I continue to wrap the executables themselves in python functional
>> wrappers, which has made the integration with other software easier, and
>> contributes to pipeline testability and robustness.
>>
>> -- Sean
>>
>> On Fri, Dec 26, 2014 at 11:02 AM, Sean True <se...@se...>
>> wrote:
>>
>>> I wanted to echo Ondrej's comment about preferring Python to bash/perl
>>> for scripting. Python wrappers for the command line utilities are useful
>>> ... I've spent a few hours systematically wrapping them, parsing the output
>>> of the --help command as a guide to functionality.
>>>
>>> This gives wrappers of the general form:
>>>
>>> def acc_lda(transition_gmm_model, features_rspecifier,
>>> posteriors_rspecifier, lda_acc_out, *args, **kwargs):
>>>     """Accumulate LDA statistics based on pdf-ids.
>>>     Executable usage:  acc-lda [options] <transition-gmm/model>
>>> <features-rspecifier> <posteriors-rspecifier> <lda-acc-out>
>>>     Options:
>>>     binary:  Write accumulators in binary mode.  (bool,true)
>>>     rand_prune:  Randomized pruning threshold for posteriors
>>>  (float,0)"""
>>>     cmd = sh.Command(kaldi_path("src/bin/acc-lda"))
>>>     option_defs = {'binary': ('binary', 'bool', 'true'), 'help':
>>> ('help', 'bool', 'false'), 'rand_prune': ('rand-prune', 'float', '0'),
>>> 'config': ('config', 'string', ''), 'print_args': ('print-args', 'bool',
>>> 'true'), 'verbose': ('verbose', 'int', '0')}
>>>     myOptions = create_options(option_defs, kwargs)
>>>     myArgs = [transition_gmm_model, features_rspecifier,
>>> posteriors_rspecifier, lda_acc_out]+list(args)
>>>     return cmd (myOptions + myArgs)
>>>
>>> There are some refinements that could be added (*args does not make
>>> sense for this function).
>>> Because of the rather elegant Python sh package (
>>> https://pypi.python.org/pypi/sh) these functions will create pipelines
>>> if composed:
>>>
>>> >>> from sh import ls, wc
>>>
>>> >>> wc(ls("."))
>>>
>>>        8      23     222
>>>
>>> There are a few places where constructing from help output is not
>>> straightforward (for instance, fstrand --help does
>>> not do the expected thing).
>>>
>>> -- Sean
>>>
>>> On Fri, Dec 19, 2014 at 6:48 AM, Ondrej Platek <ond...@gm...>
>>> wrote:
>>> >
>>> > Hi Matthew,
>>> >
>>> > I made some subjective comments below.
>>> >
>>> > PS: Note that I like the proposed wrappers, but I am not sure how
>>> boost::python is easy to install on all supported platforms.
>>> >
>>> > On Fri, Dec 19, 2014 at 9:30 AM, Matthew Aylett <
>>> mat...@gm...> wrote:
>>> >>
>>> >> Hi
>>> >>
>>> >> Apologies, I've been snowed under here.
>>> >>
>>> >> I haven' had a chance to look over your work. I also don't have any
>>> views on the 'right' way to do it. My thoughts on this are in a previous
>>> thread. See subject "Using SWIG to wrap kaldi for python" where I discussed
>>> this with ondrej platek and
>>> >> Vassil Panayotov.
>>> >>
>>> >> In the idlak branch there is an example of python wrappers that I put
>>> together some time ago. These are based on SWIG. In the end I didn't need
>>> this at this stage because in the build system command line executables
>>> work very well. Its in run time wrappers are very useful. The advantage
>>> with SWIG is that the much of the same work will also contribute to C#,
>>> Java, Perl wrappers as well. In my experience the most important were Java
>>> wrappers to help produce a library for Android. I have no experience with
>>> C# and moved to Python from Perl so only use Perl in legacy code ;-).
>>> >>
>>> >> So some questions to consider:
>>> >>
>>> >> 1. Why is python wrapping required for training. using sys.Process to
>>> run command lines, structured output directories etc mirrors the current
>>> Perl recipes, what is the added benefit in this case?
>>> >
>>> > Well bash and Perl is the current scripting language for Kaldi. For
>>> example I prefer to use Python instead of both of them.
>>> >
>>> >>
>>> >> 2. If its for run time decoding shouldn't we create a cross platfom
>>>  C API? Perhaps things have changed but C++ APIs were never cross compiler
>>> compatible in the past so you couldn't do stuff like compile using gnu and
>>> link in MSN. With a C interface you can distribute libraries. But I am
>>> possibly out of date on this.
>>> >
>>> > Well, I tried that and I gave it up since Kaldi nicely uses OpenFST
>>> and I was not able to wrap OpenFST with just plain C (It may be possible).
>>> > I used Cython and pyfst mainly because pyfst solved for me wrapping up
>>> OpenFST and I am really glad that 99% of wrapping OpenFST templates was
>>> carried out by somebody else (Victor Chahuneau).
>>> >>
>>> >>
>>> >> 3. If 2 is correct shouldn't we define our API and wrap that?
>>> Producing a formal list of functionality that should be exposed to things
>>> like client and server applications?
>>> >>
>>> >>
>>> >> I would encourage some care here. Unconstrained wrapping can lead to
>>> systems which HAVE to use the scripting language (We can already see how
>>> difficult it is to move away from the Perl scripting if you wish to). Also
>>> never, never, never reverse wrap (i.e. call python from within C++), yes it
>>> can be done but that way lays madness.
>>> >>
>>> >> v best
>>> >>
>>> >> Matthew
>>> >>
>>> >>
>>> >> On Thu, Dec 18, 2014 at 11:37 PM, Daniel Povey <dp...@gm...>
>>> wrote:
>>> >>>
>>> >>> Jan-
>>> >>> I haven't seen any objections to your setup.  I'd say we should plan
>>> >>> to include it in Kaldi at some point (e.g. within the next few
>>> >>> months), but in the meantime hopefully you can continue to work on
>>> it,
>>> >>> and maybe come up with some other examples of how it's useful to do
>>> >>> the interfacing with Python- e.g. some kind of application level or
>>> >>> service-level thing?
>>> >>> Dan
>>> >>>
>>> >>>
>>> >>> On Sat, Dec 13, 2014 at 4:01 PM, Yajie Miao <yaj...@gm...>
>>> wrote:
>>> >>> > Hi Jan,
>>> >>> > This is very nice work! In our PDNN toolkit, we also have simple
>>> python
>>> >>> > wrappers to read and write Kaldi features, mainly for DNN
>>> training. Your
>>> >>> > implementation looks like a more comprehensive version.
>>> >>> >
>>> >>> > Do you have the functions/commands to do feature splicing? I ask
>>> this
>>> >>> > because we found doing splicing on the fly with Python highly
>>> expensive.
>>> >>> > That's why we still stick to PFiles instead of Kaldi features
>>> (.scp .ark)
>>> >>> > for DNN triaining. I am very  interested to know the efficiency of
>>> your
>>> >>> > splicing implementation.
>>> >>> >
>>> >>> > Thanks,
>>> >>> > Yajie
>>> >>> >
>>> >>> > On Sat, Dec 13, 2014 at 5:59 PM, Daniel Povey <dp...@gm...>
>>> wrote:
>>> >>> >>
>>> >>> >> OK, thanks.
>>> >>> >> cc'ing Yajie in case he wants to comment.
>>> >>> >> Dan
>>> >>> >>
>>> >>> >>
>>> >>> >> On Sat, Dec 13, 2014 at 2:31 PM, Jan Chorowski <
>>> jan...@gm...>
>>> >>> >> wrote:
>>> >>> >> > Hi All,
>>> >>> >> >
>>> >>> >> > the wrapper is built during Kaldi compilation. I build it using
>>> provided
>>> >>> >> > Makefile. The build depends on:
>>> >>> >> > 1. Python and numpy (by default it queries the python
>>> interpreter found
>>> >>> >> > on
>>> >>> >> > the path for header file location)
>>> >>> >> > 2. Boost with Boost::Python library. It is quite heavy to
>>> build, but
>>> >>> >> > most
>>> >>> >> > Linux distributions ship it. Boost python doesn't require any
>>> code
>>> >>> >> > generation steps, the wrapper is defined in a normal c++ code
>>> file.
>>> >>> >> >
>>> >>> >> > During build Python and Boost libraries and Kaldi object files
>>> are
>>> >>> >> > linked
>>> >>> >> > into a CPython extention module,
>>> kaldi/src/python/kaldi_io_internal.so.
>>> >>> >> > It
>>> >>> >> > works with both static and shared Kaldi builds. Further usage
>>> requires
>>> >>> >> > that
>>> >>> >> > python finds kaldi_io.py and kaldi_io_internal.so on the
>>> PYTHONPATH - it
>>> >>> >> > can
>>> >>> >> > be for example added to the PYTHONPATH variable in the path.sh
>>> script of
>>> >>> >> > a
>>> >>> >> > recipe.
>>> >>> >> >
>>> >>> >> > Jan
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > On 12/13/2014 3:33 PM, Daniel Povey wrote:
>>> >>> >> >>
>>> >>> >> >> Also, Jan- could you send us an email explaining how this
>>> works-
>>> >>> >> >>    How does Python "see" the C++ headers?  Do you have to
>>> invoke some
>>> >>> >> >> special program, like swig?  Do you have to write some special
>>> kind of
>>> >>> >> >> header that shows how the C++ objects are to be interpreted by
>>> python?
>>> >>> >> >>   A brief example would be helpful, if so.
>>> >>> >> >>    How is the resulting program linked, if at all?  If you
>>> require
>>> >>> >> >> functions C++ libraries, are these obtained from the .a or .so
>>> files
>>> >>> >> >> at runtime, or compiled into some kind of executable-like blob
>>> at
>>> >>> >> >> compile time?  Does your framework require that Kaldi be
>>> compiled
>>> >>> >> >> using dynamic (.so) libraries?
>>> >>> >> >>
>>> >>> >> >> Dan
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >> On Sat, Dec 13, 2014 at 12:04 PM, Jan Chorowski
>>> >>> >> >> <jan...@gm...>
>>> >>> >> >> wrote:
>>> >>> >> >>>
>>> >>> >> >>> Hello Dan,
>>> >>> >> >>>
>>> >>> >> >>> thank you for the comments. I tried to make it in the Kaldi
>>> spirit,
>>> >>> >> >>> consistency is important. Of course, the scripts can be
>>> removed and
>>> >>> >> >>> replaced
>>> >>> >> >>> with some more useful examples. I don't have too much
>>> experience with
>>> >>> >> >>> bridging Python to C++, so any critique on the wrappers and
>>> the
>>> >>> >> >>> approach
>>> >>> >> >>> taken is welcome.
>>> >>> >> >>>
>>> >>> >> >>> Jan
>>> >>> >> >>>
>>> >>> >> >>>
>>> >>> >> >>> On 12/13/2014 2:55 PM, Daniel Povey wrote:
>>> >>> >> >>>>
>>> >>> >> >>>> Hi all.
>>> >>> >> >>>>   From a first look, it does look very impressive, and nicely
>>> >>> >> >>>> documented.
>>> >>> >> >>>> I would appreciate it if people on the list who have Python
>>> >>> >> >>>> experience
>>> >>> >> >>>> would comment on this- you can either reply to this thread,
>>> or to me.
>>> >>> >> >>>> I don't know if this has been done in the "natural" way, or
>>> if there
>>> >>> >> >>>> is some reason why people in the future will say, "why did
>>> you do it
>>> >>> >> >>>> this way, you should have done XXX".
>>> >>> >> >>>>
>>> >>> >> >>>> Jan:
>>> >>> >> >>>> in the scripts/ directory you seem to have some examples of
>>> how you
>>> >>> >> >>>> can create python programs that behave very much like Kaldi
>>> >>> >> >>>> command-line programs, using your framework.  This is very
>>> useful.
>>> >>> >> >>>> However, the programs
>>> >>> >> >>>>    apply-global-cmvn.py
>>> >>> >> >>>>    compute-global-cmvn-stats.py
>>> >>> >> >>>> are perhaps a little confusing because they provide the same
>>> >>> >> >>>> functionality that you could get with "compute-cmvn-stats ->
>>> >>> >> >>>> matrix-sum" and "apply-cmvn" on the output of that command;
>>> and they
>>> >>> >> >>>> do so using different formats for the CMVN information.  I
>>> know the
>>> >>> >> >>>> format of storing the CMVN stats in a two-row matrix is
>>> perhaps not
>>> >>> >> >>>> perfectly ideal, but it's a standard within Kaldi and it
>>> would be
>>> >>> >> >>>> confusing to deviate from that standard.
>>> >>> >> >>>> Of course, this is a very minor issue that doesn't affect the
>>> >>> >> >>>> validity
>>> >>> >> >>>> of the framework as a whole.  I am just pointing this out;
>>> the main
>>> >>> >> >>>> discussion should be about the framework and whether people
>>> feel it's
>>> >>> >> >>>> the "right" way to do this.
>>> >>> >> >>>>
>>> >>> >> >>>> Dan
>>> >>> >> >>>>
>>> >>> >> >>>> On Sat, Dec 13, 2014 at 6:28 AM, Jan Chorowski
>>> >>> >> >>>> <jan...@gm...>
>>> >>> >> >>>> wrote:
>>> >>> >> >>>>>
>>> >>> >> >>>>> Hi all!
>>> >>> >> >>>>>
>>> >>> >> >>>>> I've written wrappers to access Kaldi data files from
>>> within Python
>>> >>> >> >>>>> using boost::python (the code is on github
>>> >>> >> >>>>>
>>> https://github.com/janchorowski/kaldi-git/tree/python/src/python).
>>> >>> >> >>>>> If
>>> >>> >> >>>>> you think this would be an interesting addition please
>>> instruct me
>>> >>> >> >>>>> how
>>> >>> >> >>>>> to contribute.
>>> >>> >> >>>>>
>>> >>> >> >>>>> Best Regards,
>>> >>> >> >>>>> Jan Chorowski
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> ------------------------------------------------------------------------------
>>> >>> >> >>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT
>>> Server
>>> >>> >> >>>>> from Actuate! Instantly Supercharge Your Business Reports
>>> and
>>> >>> >> >>>>> Dashboards
>>> >>> >> >>>>> with Interactivity, Sharing, Native Excel Exports, App
>>> Integration &
>>> >>> >> >>>>> more
>>> >>> >> >>>>> Get technology previously reserved for billion-dollar
>>> corporations,
>>> >>> >> >>>>> FREE
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> >>> >> >>>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>> >>> >> >>>>> _______________________________________________
>>> >>> >> >>>>> Kaldi-developers mailing list
>>> >>> >> >>>>> Kal...@li...
>>> >>> >> >>>>>
>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>> >>> >> >>>
>>> >>> >> >>>
>>> >>> >> >
>>> >>> >
>>> >>> >
>>> >>>
>>> >>>
>>> ------------------------------------------------------------------------------
>>> >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> >>> from Actuate! Instantly Supercharge Your Business Reports and
>>> Dashboards
>>> >>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>> more
>>> >>> Get technology previously reserved for billion-dollar corporations,
>>> FREE
>>> >>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>> >>> _______________________________________________
>>> >>> Kaldi-developers mailing list
>>> >>> Kal...@li...
>>> >>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>> >>
>>> >>
>>> >>
>>> ------------------------------------------------------------------------------
>>> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> >> from Actuate! Instantly Supercharge Your Business Reports and
>>> Dashboards
>>> >> with Interactivity, Sharing, Native Excel Exports, App Integration &
>>> more
>>> >> Get technology previously reserved for billion-dollar corporations,
>>> FREE
>>> >>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>> >> _______________________________________________
>>> >> Kaldi-developers mailing list
>>> >> Kal...@li...
>>> >> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>> >>
>>> >
>>> >
>>> > --
>>> > Ondřej Plátek, +420 737 758 650, skype:ondrejplatek,
>>> ond...@gm...
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>>> > from Actuate! Instantly Supercharge Your Business Reports and
>>> Dashboards
>>> > with Interactivity, Sharing, Native Excel Exports, App Integration &
>>> more
>>> > Get technology previously reserved for billion-dollar corporations,
>>> FREE
>>> >
>>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>>> > _______________________________________________
>>> > Kaldi-developers mailing list
>>> > Kal...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>> >
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Kaldi-developers mailing list
>> Kal...@li...
>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>
>>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>

Re: [Kaldi-developers] python wrappers for Kaldi

[Jan T. <af...@ce...>]

Personally, if we were to include wrappers directly into kaldi, I'd prefer
SWIG as the wrapper generator. I worked to some extent with ctypes,
boost::python and swig and all are usable and "just fine" for python.
The concern I have is however, if this is going to be put into kaldi trunk
and we want it to be really useful, then someone will have to maintain it,
take the responsibility for it and make it in sync with the C/C++ code,
which given the rate of kaldi development will need more than negligible
commitment. Yes we can argue that "the community will keep it updated" but
frankly, I didn't see any successful project working without someone
committing to do even the ugly/boring/maintenance work on regular basis.
And for that a wider user base might be more stimulating in the sense that
the maintainer would see the wrappers are used (which would yield more
feedback/bugreports). Which means (at least to me) that more languages
should be supported -- at least python, perl, java...  From all those
wrapper generators, only SWIG can do that -- i.e. after writing one
interface file, it can generate wrappers for those langs (and some other as
well).

Just my two cents..
y.


On Mon, Feb 16, 2015 at 8:52 AM, Sean True <se...@se...>
wrote:

> I wanted to bring up the integration of the very useful kaldi_io package
> that Jan Chorowski made available in December. Is there any consensus on
> whether to provide this code as (probably an optional) part of the Kaldi
> release? I understand that Boost-Python is a relatively heavy requirement,
> but it is easily available on OSX and Linux.
>
> I continue to wrap the executables themselves in python functional
> wrappers, which has made the integration with other software easier, and
> contributes to pipeline testability and robustness.
>
> -- Sean
>
> On Fri, Dec 26, 2014 at 11:02 AM, Sean True <se...@se...>
> wrote:
>
>> I wanted to echo Ondrej's comment about preferring Python to bash/perl
>> for scripting. Python wrappers for the command line utilities are useful
>> ... I've spent a few hours systematically wrapping them, parsing the output
>> of the --help command as a guide to functionality.
>>
>> This gives wrappers of the general form:
>>
>> def acc_lda(transition_gmm_model, features_rspecifier,
>> posteriors_rspecifier, lda_acc_out, *args, **kwargs):
>>     """Accumulate LDA statistics based on pdf-ids.
>>     Executable usage:  acc-lda [options] <transition-gmm/model>
>> <features-rspecifier> <posteriors-rspecifier> <lda-acc-out>
>>     Options:
>>     binary:  Write accumulators in binary mode.  (bool,true)
>>     rand_prune:  Randomized pruning threshold for posteriors  (float,0)"""
>>     cmd = sh.Command(kaldi_path("src/bin/acc-lda"))
>>     option_defs = {'binary': ('binary', 'bool', 'true'), 'help': ('help',
>> 'bool', 'false'), 'rand_prune': ('rand-prune', 'float', '0'), 'config':
>> ('config', 'string', ''), 'print_args': ('print-args', 'bool', 'true'),
>> 'verbose': ('verbose', 'int', '0')}
>>     myOptions = create_options(option_defs, kwargs)
>>     myArgs = [transition_gmm_model, features_rspecifier,
>> posteriors_rspecifier, lda_acc_out]+list(args)
>>     return cmd (myOptions + myArgs)
>>
>> There are some refinements that could be added (*args does not make sense
>> for this function).
>> Because of the rather elegant Python sh package (
>> https://pypi.python.org/pypi/sh) these functions will create pipelines
>> if composed:
>>
>> >>> from sh import ls, wc
>>
>> >>> wc(ls("."))
>>
>>        8      23     222
>>
>> There are a few places where constructing from help output is not
>> straightforward (for instance, fstrand --help does
>> not do the expected thing).
>>
>> -- Sean
>>
>> On Fri, Dec 19, 2014 at 6:48 AM, Ondrej Platek <ond...@gm...>
>> wrote:
>> >
>> > Hi Matthew,
>> >
>> > I made some subjective comments below.
>> >
>> > PS: Note that I like the proposed wrappers, but I am not sure how
>> boost::python is easy to install on all supported platforms.
>> >
>> > On Fri, Dec 19, 2014 at 9:30 AM, Matthew Aylett <
>> mat...@gm...> wrote:
>> >>
>> >> Hi
>> >>
>> >> Apologies, I've been snowed under here.
>> >>
>> >> I haven' had a chance to look over your work. I also don't have any
>> views on the 'right' way to do it. My thoughts on this are in a previous
>> thread. See subject "Using SWIG to wrap kaldi for python" where I discussed
>> this with ondrej platek and
>> >> Vassil Panayotov.
>> >>
>> >> In the idlak branch there is an example of python wrappers that I put
>> together some time ago. These are based on SWIG. In the end I didn't need
>> this at this stage because in the build system command line executables
>> work very well. Its in run time wrappers are very useful. The advantage
>> with SWIG is that the much of the same work will also contribute to C#,
>> Java, Perl wrappers as well. In my experience the most important were Java
>> wrappers to help produce a library for Android. I have no experience with
>> C# and moved to Python from Perl so only use Perl in legacy code ;-).
>> >>
>> >> So some questions to consider:
>> >>
>> >> 1. Why is python wrapping required for training. using sys.Process to
>> run command lines, structured output directories etc mirrors the current
>> Perl recipes, what is the added benefit in this case?
>> >
>> > Well bash and Perl is the current scripting language for Kaldi. For
>> example I prefer to use Python instead of both of them.
>> >
>> >>
>> >> 2. If its for run time decoding shouldn't we create a cross platfom  C
>> API? Perhaps things have changed but C++ APIs were never cross compiler
>> compatible in the past so you couldn't do stuff like compile using gnu and
>> link in MSN. With a C interface you can distribute libraries. But I am
>> possibly out of date on this.
>> >
>> > Well, I tried that and I gave it up since Kaldi nicely uses OpenFST and
>> I was not able to wrap OpenFST with just plain C (It may be possible).
>> > I used Cython and pyfst mainly because pyfst solved for me wrapping up
>> OpenFST and I am really glad that 99% of wrapping OpenFST templates was
>> carried out by somebody else (Victor Chahuneau).
>> >>
>> >>
>> >> 3. If 2 is correct shouldn't we define our API and wrap that?
>> Producing a formal list of functionality that should be exposed to things
>> like client and server applications?
>> >>
>> >>
>> >> I would encourage some care here. Unconstrained wrapping can lead to
>> systems which HAVE to use the scripting language (We can already see how
>> difficult it is to move away from the Perl scripting if you wish to). Also
>> never, never, never reverse wrap (i.e. call python from within C++), yes it
>> can be done but that way lays madness.
>> >>
>> >> v best
>> >>
>> >> Matthew
>> >>
>> >>
>> >> On Thu, Dec 18, 2014 at 11:37 PM, Daniel Povey <dp...@gm...>
>> wrote:
>> >>>
>> >>> Jan-
>> >>> I haven't seen any objections to your setup.  I'd say we should plan
>> >>> to include it in Kaldi at some point (e.g. within the next few
>> >>> months), but in the meantime hopefully you can continue to work on it,
>> >>> and maybe come up with some other examples of how it's useful to do
>> >>> the interfacing with Python- e.g. some kind of application level or
>> >>> service-level thing?
>> >>> Dan
>> >>>
>> >>>
>> >>> On Sat, Dec 13, 2014 at 4:01 PM, Yajie Miao <yaj...@gm...>
>> wrote:
>> >>> > Hi Jan,
>> >>> > This is very nice work! In our PDNN toolkit, we also have simple
>> python
>> >>> > wrappers to read and write Kaldi features, mainly for DNN training.
>> Your
>> >>> > implementation looks like a more comprehensive version.
>> >>> >
>> >>> > Do you have the functions/commands to do feature splicing? I ask
>> this
>> >>> > because we found doing splicing on the fly with Python highly
>> expensive.
>> >>> > That's why we still stick to PFiles instead of Kaldi features (.scp
>> .ark)
>> >>> > for DNN triaining. I am very  interested to know the efficiency of
>> your
>> >>> > splicing implementation.
>> >>> >
>> >>> > Thanks,
>> >>> > Yajie
>> >>> >
>> >>> > On Sat, Dec 13, 2014 at 5:59 PM, Daniel Povey <dp...@gm...>
>> wrote:
>> >>> >>
>> >>> >> OK, thanks.
>> >>> >> cc'ing Yajie in case he wants to comment.
>> >>> >> Dan
>> >>> >>
>> >>> >>
>> >>> >> On Sat, Dec 13, 2014 at 2:31 PM, Jan Chorowski <
>> jan...@gm...>
>> >>> >> wrote:
>> >>> >> > Hi All,
>> >>> >> >
>> >>> >> > the wrapper is built during Kaldi compilation. I build it using
>> provided
>> >>> >> > Makefile. The build depends on:
>> >>> >> > 1. Python and numpy (by default it queries the python
>> interpreter found
>> >>> >> > on
>> >>> >> > the path for header file location)
>> >>> >> > 2. Boost with Boost::Python library. It is quite heavy to build,
>> but
>> >>> >> > most
>> >>> >> > Linux distributions ship it. Boost python doesn't require any
>> code
>> >>> >> > generation steps, the wrapper is defined in a normal c++ code
>> file.
>> >>> >> >
>> >>> >> > During build Python and Boost libraries and Kaldi object files
>> are
>> >>> >> > linked
>> >>> >> > into a CPython extention module,
>> kaldi/src/python/kaldi_io_internal.so.
>> >>> >> > It
>> >>> >> > works with both static and shared Kaldi builds. Further usage
>> requires
>> >>> >> > that
>> >>> >> > python finds kaldi_io.py and kaldi_io_internal.so on the
>> PYTHONPATH - it
>> >>> >> > can
>> >>> >> > be for example added to the PYTHONPATH variable in the path.sh
>> script of
>> >>> >> > a
>> >>> >> > recipe.
>> >>> >> >
>> >>> >> > Jan
>> >>> >> >
>> >>> >> >
>> >>> >> > On 12/13/2014 3:33 PM, Daniel Povey wrote:
>> >>> >> >>
>> >>> >> >> Also, Jan- could you send us an email explaining how this works-
>> >>> >> >>    How does Python "see" the C++ headers?  Do you have to
>> invoke some
>> >>> >> >> special program, like swig?  Do you have to write some special
>> kind of
>> >>> >> >> header that shows how the C++ objects are to be interpreted by
>> python?
>> >>> >> >>   A brief example would be helpful, if so.
>> >>> >> >>    How is the resulting program linked, if at all?  If you
>> require
>> >>> >> >> functions C++ libraries, are these obtained from the .a or .so
>> files
>> >>> >> >> at runtime, or compiled into some kind of executable-like blob
>> at
>> >>> >> >> compile time?  Does your framework require that Kaldi be
>> compiled
>> >>> >> >> using dynamic (.so) libraries?
>> >>> >> >>
>> >>> >> >> Dan
>> >>> >> >>
>> >>> >> >>
>> >>> >> >> On Sat, Dec 13, 2014 at 12:04 PM, Jan Chorowski
>> >>> >> >> <jan...@gm...>
>> >>> >> >> wrote:
>> >>> >> >>>
>> >>> >> >>> Hello Dan,
>> >>> >> >>>
>> >>> >> >>> thank you for the comments. I tried to make it in the Kaldi
>> spirit,
>> >>> >> >>> consistency is important. Of course, the scripts can be
>> removed and
>> >>> >> >>> replaced
>> >>> >> >>> with some more useful examples. I don't have too much
>> experience with
>> >>> >> >>> bridging Python to C++, so any critique on the wrappers and the
>> >>> >> >>> approach
>> >>> >> >>> taken is welcome.
>> >>> >> >>>
>> >>> >> >>> Jan
>> >>> >> >>>
>> >>> >> >>>
>> >>> >> >>> On 12/13/2014 2:55 PM, Daniel Povey wrote:
>> >>> >> >>>>
>> >>> >> >>>> Hi all.
>> >>> >> >>>>   From a first look, it does look very impressive, and nicely
>> >>> >> >>>> documented.
>> >>> >> >>>> I would appreciate it if people on the list who have Python
>> >>> >> >>>> experience
>> >>> >> >>>> would comment on this- you can either reply to this thread,
>> or to me.
>> >>> >> >>>> I don't know if this has been done in the "natural" way, or
>> if there
>> >>> >> >>>> is some reason why people in the future will say, "why did
>> you do it
>> >>> >> >>>> this way, you should have done XXX".
>> >>> >> >>>>
>> >>> >> >>>> Jan:
>> >>> >> >>>> in the scripts/ directory you seem to have some examples of
>> how you
>> >>> >> >>>> can create python programs that behave very much like Kaldi
>> >>> >> >>>> command-line programs, using your framework.  This is very
>> useful.
>> >>> >> >>>> However, the programs
>> >>> >> >>>>    apply-global-cmvn.py
>> >>> >> >>>>    compute-global-cmvn-stats.py
>> >>> >> >>>> are perhaps a little confusing because they provide the same
>> >>> >> >>>> functionality that you could get with "compute-cmvn-stats ->
>> >>> >> >>>> matrix-sum" and "apply-cmvn" on the output of that command;
>> and they
>> >>> >> >>>> do so using different formats for the CMVN information.  I
>> know the
>> >>> >> >>>> format of storing the CMVN stats in a two-row matrix is
>> perhaps not
>> >>> >> >>>> perfectly ideal, but it's a standard within Kaldi and it
>> would be
>> >>> >> >>>> confusing to deviate from that standard.
>> >>> >> >>>> Of course, this is a very minor issue that doesn't affect the
>> >>> >> >>>> validity
>> >>> >> >>>> of the framework as a whole.  I am just pointing this out;
>> the main
>> >>> >> >>>> discussion should be about the framework and whether people
>> feel it's
>> >>> >> >>>> the "right" way to do this.
>> >>> >> >>>>
>> >>> >> >>>> Dan
>> >>> >> >>>>
>> >>> >> >>>> On Sat, Dec 13, 2014 at 6:28 AM, Jan Chorowski
>> >>> >> >>>> <jan...@gm...>
>> >>> >> >>>> wrote:
>> >>> >> >>>>>
>> >>> >> >>>>> Hi all!
>> >>> >> >>>>>
>> >>> >> >>>>> I've written wrappers to access Kaldi data files from within
>> Python
>> >>> >> >>>>> using boost::python (the code is on github
>> >>> >> >>>>>
>> https://github.com/janchorowski/kaldi-git/tree/python/src/python).
>> >>> >> >>>>> If
>> >>> >> >>>>> you think this would be an interesting addition please
>> instruct me
>> >>> >> >>>>> how
>> >>> >> >>>>> to contribute.
>> >>> >> >>>>>
>> >>> >> >>>>> Best Regards,
>> >>> >> >>>>> Jan Chorowski
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>
>> ------------------------------------------------------------------------------
>> >>> >> >>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT
>> Server
>> >>> >> >>>>> from Actuate! Instantly Supercharge Your Business Reports and
>> >>> >> >>>>> Dashboards
>> >>> >> >>>>> with Interactivity, Sharing, Native Excel Exports, App
>> Integration &
>> >>> >> >>>>> more
>> >>> >> >>>>> Get technology previously reserved for billion-dollar
>> corporations,
>> >>> >> >>>>> FREE
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>
>> >>> >> >>>>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> >>> >> >>>>> _______________________________________________
>> >>> >> >>>>> Kaldi-developers mailing list
>> >>> >> >>>>> Kal...@li...
>> >>> >> >>>>>
>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>> >>> >> >>>
>> >>> >> >>>
>> >>> >> >
>> >>> >
>> >>> >
>> >>>
>> >>>
>> ------------------------------------------------------------------------------
>> >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> >>> from Actuate! Instantly Supercharge Your Business Reports and
>> Dashboards
>> >>> with Interactivity, Sharing, Native Excel Exports, App Integration &
>> more
>> >>> Get technology previously reserved for billion-dollar corporations,
>> FREE
>> >>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> >>> _______________________________________________
>> >>> Kaldi-developers mailing list
>> >>> Kal...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> >> from Actuate! Instantly Supercharge Your Business Reports and
>> Dashboards
>> >> with Interactivity, Sharing, Native Excel Exports, App Integration &
>> more
>> >> Get technology previously reserved for billion-dollar corporations,
>> FREE
>> >>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> >> _______________________________________________
>> >> Kaldi-developers mailing list
>> >> Kal...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>> >>
>> >
>> >
>> > --
>> > Ondřej Plátek, +420 737 758 650, skype:ondrejplatek,
>> ond...@gm...
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> > with Interactivity, Sharing, Native Excel Exports, App Integration &
>> more
>> > Get technology previously reserved for billion-dollar corporations, FREE
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> > _______________________________________________
>> > Kaldi-developers mailing list
>> > Kal...@li...
>> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>> >
>>
>
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>

Re: [Kaldi-developers] python wrappers for Kaldi

[Sean T. <se...@se...>]

I wanted to bring up the integration of the very useful kaldi_io package
that Jan Chorowski made available in December. Is there any consensus on
whether to provide this code as (probably an optional) part of the Kaldi
release? I understand that Boost-Python is a relatively heavy requirement,
but it is easily available on OSX and Linux.

I continue to wrap the executables themselves in python functional
wrappers, which has made the integration with other software easier, and
contributes to pipeline testability and robustness.

-- Sean

On Fri, Dec 26, 2014 at 11:02 AM, Sean True <se...@se...>
wrote:

> I wanted to echo Ondrej's comment about preferring Python to bash/perl for
> scripting. Python wrappers for the command line utilities are useful ...
> I've spent a few hours systematically wrapping them, parsing the output of
> the --help command as a guide to functionality.
>
> This gives wrappers of the general form:
>
> def acc_lda(transition_gmm_model, features_rspecifier,
> posteriors_rspecifier, lda_acc_out, *args, **kwargs):
>     """Accumulate LDA statistics based on pdf-ids.
>     Executable usage:  acc-lda [options] <transition-gmm/model>
> <features-rspecifier> <posteriors-rspecifier> <lda-acc-out>
>     Options:
>     binary:  Write accumulators in binary mode.  (bool,true)
>     rand_prune:  Randomized pruning threshold for posteriors  (float,0)"""
>     cmd = sh.Command(kaldi_path("src/bin/acc-lda"))
>     option_defs = {'binary': ('binary', 'bool', 'true'), 'help': ('help',
> 'bool', 'false'), 'rand_prune': ('rand-prune', 'float', '0'), 'config':
> ('config', 'string', ''), 'print_args': ('print-args', 'bool', 'true'),
> 'verbose': ('verbose', 'int', '0')}
>     myOptions = create_options(option_defs, kwargs)
>     myArgs = [transition_gmm_model, features_rspecifier,
> posteriors_rspecifier, lda_acc_out]+list(args)
>     return cmd (myOptions + myArgs)
>
> There are some refinements that could be added (*args does not make sense
> for this function).
> Because of the rather elegant Python sh package (
> https://pypi.python.org/pypi/sh) these functions will create pipelines if
> composed:
>
> >>> from sh import ls, wc
>
> >>> wc(ls("."))
>
>        8      23     222
>
> There are a few places where constructing from help output is not
> straightforward (for instance, fstrand --help does
> not do the expected thing).
>
> -- Sean
>
> On Fri, Dec 19, 2014 at 6:48 AM, Ondrej Platek <ond...@gm...>
> wrote:
> >
> > Hi Matthew,
> >
> > I made some subjective comments below.
> >
> > PS: Note that I like the proposed wrappers, but I am not sure how
> boost::python is easy to install on all supported platforms.
> >
> > On Fri, Dec 19, 2014 at 9:30 AM, Matthew Aylett <mat...@gm...>
> wrote:
> >>
> >> Hi
> >>
> >> Apologies, I've been snowed under here.
> >>
> >> I haven' had a chance to look over your work. I also don't have any
> views on the 'right' way to do it. My thoughts on this are in a previous
> thread. See subject "Using SWIG to wrap kaldi for python" where I discussed
> this with ondrej platek and
> >> Vassil Panayotov.
> >>
> >> In the idlak branch there is an example of python wrappers that I put
> together some time ago. These are based on SWIG. In the end I didn't need
> this at this stage because in the build system command line executables
> work very well. Its in run time wrappers are very useful. The advantage
> with SWIG is that the much of the same work will also contribute to C#,
> Java, Perl wrappers as well. In my experience the most important were Java
> wrappers to help produce a library for Android. I have no experience with
> C# and moved to Python from Perl so only use Perl in legacy code ;-).
> >>
> >> So some questions to consider:
> >>
> >> 1. Why is python wrapping required for training. using sys.Process to
> run command lines, structured output directories etc mirrors the current
> Perl recipes, what is the added benefit in this case?
> >
> > Well bash and Perl is the current scripting language for Kaldi. For
> example I prefer to use Python instead of both of them.
> >
> >>
> >> 2. If its for run time decoding shouldn't we create a cross platfom  C
> API? Perhaps things have changed but C++ APIs were never cross compiler
> compatible in the past so you couldn't do stuff like compile using gnu and
> link in MSN. With a C interface you can distribute libraries. But I am
> possibly out of date on this.
> >
> > Well, I tried that and I gave it up since Kaldi nicely uses OpenFST and
> I was not able to wrap OpenFST with just plain C (It may be possible).
> > I used Cython and pyfst mainly because pyfst solved for me wrapping up
> OpenFST and I am really glad that 99% of wrapping OpenFST templates was
> carried out by somebody else (Victor Chahuneau).
> >>
> >>
> >> 3. If 2 is correct shouldn't we define our API and wrap that? Producing
> a formal list of functionality that should be exposed to things like client
> and server applications?
> >>
> >>
> >> I would encourage some care here. Unconstrained wrapping can lead to
> systems which HAVE to use the scripting language (We can already see how
> difficult it is to move away from the Perl scripting if you wish to). Also
> never, never, never reverse wrap (i.e. call python from within C++), yes it
> can be done but that way lays madness.
> >>
> >> v best
> >>
> >> Matthew
> >>
> >>
> >> On Thu, Dec 18, 2014 at 11:37 PM, Daniel Povey <dp...@gm...>
> wrote:
> >>>
> >>> Jan-
> >>> I haven't seen any objections to your setup.  I'd say we should plan
> >>> to include it in Kaldi at some point (e.g. within the next few
> >>> months), but in the meantime hopefully you can continue to work on it,
> >>> and maybe come up with some other examples of how it's useful to do
> >>> the interfacing with Python- e.g. some kind of application level or
> >>> service-level thing?
> >>> Dan
> >>>
> >>>
> >>> On Sat, Dec 13, 2014 at 4:01 PM, Yajie Miao <yaj...@gm...>
> wrote:
> >>> > Hi Jan,
> >>> > This is very nice work! In our PDNN toolkit, we also have simple
> python
> >>> > wrappers to read and write Kaldi features, mainly for DNN training.
> Your
> >>> > implementation looks like a more comprehensive version.
> >>> >
> >>> > Do you have the functions/commands to do feature splicing? I ask this
> >>> > because we found doing splicing on the fly with Python highly
> expensive.
> >>> > That's why we still stick to PFiles instead of Kaldi features (.scp
> .ark)
> >>> > for DNN triaining. I am very  interested to know the efficiency of
> your
> >>> > splicing implementation.
> >>> >
> >>> > Thanks,
> >>> > Yajie
> >>> >
> >>> > On Sat, Dec 13, 2014 at 5:59 PM, Daniel Povey <dp...@gm...>
> wrote:
> >>> >>
> >>> >> OK, thanks.
> >>> >> cc'ing Yajie in case he wants to comment.
> >>> >> Dan
> >>> >>
> >>> >>
> >>> >> On Sat, Dec 13, 2014 at 2:31 PM, Jan Chorowski <
> jan...@gm...>
> >>> >> wrote:
> >>> >> > Hi All,
> >>> >> >
> >>> >> > the wrapper is built during Kaldi compilation. I build it using
> provided
> >>> >> > Makefile. The build depends on:
> >>> >> > 1. Python and numpy (by default it queries the python interpreter
> found
> >>> >> > on
> >>> >> > the path for header file location)
> >>> >> > 2. Boost with Boost::Python library. It is quite heavy to build,
> but
> >>> >> > most
> >>> >> > Linux distributions ship it. Boost python doesn't require any code
> >>> >> > generation steps, the wrapper is defined in a normal c++ code
> file.
> >>> >> >
> >>> >> > During build Python and Boost libraries and Kaldi object files are
> >>> >> > linked
> >>> >> > into a CPython extention module,
> kaldi/src/python/kaldi_io_internal.so.
> >>> >> > It
> >>> >> > works with both static and shared Kaldi builds. Further usage
> requires
> >>> >> > that
> >>> >> > python finds kaldi_io.py and kaldi_io_internal.so on the
> PYTHONPATH - it
> >>> >> > can
> >>> >> > be for example added to the PYTHONPATH variable in the path.sh
> script of
> >>> >> > a
> >>> >> > recipe.
> >>> >> >
> >>> >> > Jan
> >>> >> >
> >>> >> >
> >>> >> > On 12/13/2014 3:33 PM, Daniel Povey wrote:
> >>> >> >>
> >>> >> >> Also, Jan- could you send us an email explaining how this works-
> >>> >> >>    How does Python "see" the C++ headers?  Do you have to invoke
> some
> >>> >> >> special program, like swig?  Do you have to write some special
> kind of
> >>> >> >> header that shows how the C++ objects are to be interpreted by
> python?
> >>> >> >>   A brief example would be helpful, if so.
> >>> >> >>    How is the resulting program linked, if at all?  If you
> require
> >>> >> >> functions C++ libraries, are these obtained from the .a or .so
> files
> >>> >> >> at runtime, or compiled into some kind of executable-like blob at
> >>> >> >> compile time?  Does your framework require that Kaldi be compiled
> >>> >> >> using dynamic (.so) libraries?
> >>> >> >>
> >>> >> >> Dan
> >>> >> >>
> >>> >> >>
> >>> >> >> On Sat, Dec 13, 2014 at 12:04 PM, Jan Chorowski
> >>> >> >> <jan...@gm...>
> >>> >> >> wrote:
> >>> >> >>>
> >>> >> >>> Hello Dan,
> >>> >> >>>
> >>> >> >>> thank you for the comments. I tried to make it in the Kaldi
> spirit,
> >>> >> >>> consistency is important. Of course, the scripts can be removed
> and
> >>> >> >>> replaced
> >>> >> >>> with some more useful examples. I don't have too much
> experience with
> >>> >> >>> bridging Python to C++, so any critique on the wrappers and the
> >>> >> >>> approach
> >>> >> >>> taken is welcome.
> >>> >> >>>
> >>> >> >>> Jan
> >>> >> >>>
> >>> >> >>>
> >>> >> >>> On 12/13/2014 2:55 PM, Daniel Povey wrote:
> >>> >> >>>>
> >>> >> >>>> Hi all.
> >>> >> >>>>   From a first look, it does look very impressive, and nicely
> >>> >> >>>> documented.
> >>> >> >>>> I would appreciate it if people on the list who have Python
> >>> >> >>>> experience
> >>> >> >>>> would comment on this- you can either reply to this thread, or
> to me.
> >>> >> >>>> I don't know if this has been done in the "natural" way, or if
> there
> >>> >> >>>> is some reason why people in the future will say, "why did you
> do it
> >>> >> >>>> this way, you should have done XXX".
> >>> >> >>>>
> >>> >> >>>> Jan:
> >>> >> >>>> in the scripts/ directory you seem to have some examples of
> how you
> >>> >> >>>> can create python programs that behave very much like Kaldi
> >>> >> >>>> command-line programs, using your framework.  This is very
> useful.
> >>> >> >>>> However, the programs
> >>> >> >>>>    apply-global-cmvn.py
> >>> >> >>>>    compute-global-cmvn-stats.py
> >>> >> >>>> are perhaps a little confusing because they provide the same
> >>> >> >>>> functionality that you could get with "compute-cmvn-stats ->
> >>> >> >>>> matrix-sum" and "apply-cmvn" on the output of that command;
> and they
> >>> >> >>>> do so using different formats for the CMVN information.  I
> know the
> >>> >> >>>> format of storing the CMVN stats in a two-row matrix is
> perhaps not
> >>> >> >>>> perfectly ideal, but it's a standard within Kaldi and it would
> be
> >>> >> >>>> confusing to deviate from that standard.
> >>> >> >>>> Of course, this is a very minor issue that doesn't affect the
> >>> >> >>>> validity
> >>> >> >>>> of the framework as a whole.  I am just pointing this out; the
> main
> >>> >> >>>> discussion should be about the framework and whether people
> feel it's
> >>> >> >>>> the "right" way to do this.
> >>> >> >>>>
> >>> >> >>>> Dan
> >>> >> >>>>
> >>> >> >>>> On Sat, Dec 13, 2014 at 6:28 AM, Jan Chorowski
> >>> >> >>>> <jan...@gm...>
> >>> >> >>>> wrote:
> >>> >> >>>>>
> >>> >> >>>>> Hi all!
> >>> >> >>>>>
> >>> >> >>>>> I've written wrappers to access Kaldi data files from within
> Python
> >>> >> >>>>> using boost::python (the code is on github
> >>> >> >>>>>
> https://github.com/janchorowski/kaldi-git/tree/python/src/python).
> >>> >> >>>>> If
> >>> >> >>>>> you think this would be an interesting addition please
> instruct me
> >>> >> >>>>> how
> >>> >> >>>>> to contribute.
> >>> >> >>>>>
> >>> >> >>>>> Best Regards,
> >>> >> >>>>> Jan Chorowski
> >>> >> >>>>>
> >>> >> >>>>>
> >>> >> >>>>>
> >>> >> >>>>>
> >>> >> >>>>>
> >>> >> >>>>>
> ------------------------------------------------------------------------------
> >>> >> >>>>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT
> Server
> >>> >> >>>>> from Actuate! Instantly Supercharge Your Business Reports and
> >>> >> >>>>> Dashboards
> >>> >> >>>>> with Interactivity, Sharing, Native Excel Exports, App
> Integration &
> >>> >> >>>>> more
> >>> >> >>>>> Get technology previously reserved for billion-dollar
> corporations,
> >>> >> >>>>> FREE
> >>> >> >>>>>
> >>> >> >>>>>
> >>> >> >>>>>
> >>> >> >>>>>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> >>> >> >>>>> _______________________________________________
> >>> >> >>>>> Kaldi-developers mailing list
> >>> >> >>>>> Kal...@li...
> >>> >> >>>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
> >>> >> >>>
> >>> >> >>>
> >>> >> >
> >>> >
> >>> >
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >>> from Actuate! Instantly Supercharge Your Business Reports and
> Dashboards
> >>> with Interactivity, Sharing, Native Excel Exports, App Integration &
> more
> >>> Get technology previously reserved for billion-dollar corporations,
> FREE
> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> >>> _______________________________________________
> >>> Kaldi-developers mailing list
> >>> Kal...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> >> with Interactivity, Sharing, Native Excel Exports, App Integration &
> more
> >> Get technology previously reserved for billion-dollar corporations, FREE
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> >> _______________________________________________
> >> Kaldi-developers mailing list
> >> Kal...@li...
> >> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
> >>
> >
> >
> > --
> > Ondřej Plátek, +420 737 758 650, skype:ondrejplatek,
> ond...@gm...
> >
> >
> ------------------------------------------------------------------------------
> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> > with Interactivity, Sharing, Native Excel Exports, App Integration & more
> > Get technology previously reserved for billion-dollar corporations, FREE
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Kaldi-developers mailing list
> > Kal...@li...
> > https://lists.sourceforge.net/lists/listinfo/kaldi-developers
> >
>

Re: [Kaldi-developers] Computing phone likelihoods in Kaldi for accent detection

[Daniel P. <dp...@gm...>]

It would require a little bit of messing around to get the likelihoods for
the individual phones.
E.g. lattice-1best to get the 1-best transcript from the lattice (as a
linear lattice), then lattice-align-phones, then gmm-rescore-lattice to
recompute the acoustic scores on the lattice arcs.

However, I don't think this would be very useful for you, since the two
acoustic models will likely produce different alignments, so you would be
comparing scores obtained from different segments of the audio.  Generally
speaking, the differences in likelihood between two different frames are
larger than the difference in likelihood for the same frame and two
different (but plausible) acoustic models.  So you'll mostly be comparing
irrelevant differences, even if you normalize for the numrer of frames.


Dan


Hi everybody,
> Is there any way to compute likelihood of a an  utterance,  given a model
> (in gmm-hmm kaldi format ), a specific phoneme and a given utterance ?
>
> More specifically, I need this for accent classification. I have two
> acoustic models learned from American and British accents. Now given an
> audio file + its transcript, I want to use Likelihood ratio test to decide
> whether it is American or British accent.
>
> I though to compute the likelihood ratio for the most discriminative
> phones.  Hence after alignment in phone level I want to compute
> the L(x1,...xn;Ha,PH)/L(x1,...xn;Hb,PH)
> where
> L is the likelihood function.
> Ha and Hb are the american and British models, respectively.
> PH is the phone index
> x1,x2,....xn are the feature vectors of a specific phone.
>
> In a nut shell i need a forward algorithm for HMM.
>
> Thanks in advance
> Saman
>
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>

[Kaldi-developers] Computing phone likelihoods in Kaldi for accent detection

[Saman M. <smo...@gm...>]

Hi everybody,
Is there any way to compute likelihood of a an  utterance,  given a model
(in gmm-hmm kaldi format ), a specific phoneme and a given utterance ?

More specifically, I need this for accent classification. I have two
acoustic models learned from American and British accents. Now given an
audio file + its transcript, I want to use Likelihood ratio test to decide
whether it is American or British accent.

I though to compute the likelihood ratio for the most discriminative
phones.  Hence after alignment in phone level I want to compute
the L(x1,...xn;Ha,PH)/L(x1,...xn;Hb,PH)
where
L is the likelihood function.
Ha and Hb are the american and British models, respectively.
PH is the phone index
x1,x2,....xn are the feature vectors of a specific phone.

In a nut shell i need a forward algorithm for HMM.

Thanks in advance
Saman

Re: [Kaldi-developers] Discrete Symbol based acoustic models

[Daniel P. <dp...@gm...>]

Just like discrete HMMs, A* and stack decoders are things that no-one has
used for over a decade.  So, no.  People use Viterbi decoders with
beam-pruning now.
Dan


On Wed, Feb 11, 2015 at 12:42 AM, Himanshu Joshi <hj...@us...> wrote:

> Daniel,
>
>  Thanks for your response. For now, I will try to work with HTK's VQ tool
> and use symbolic inputs.
>
>  One more question: Are you aware of any toolkits that implement the
> A*/Stack Decoder, possibly with a PCFG assisted language model?
>
> Thanks,
> Himanshu
>
> On Tue, Feb 10, 2015 at 3:52 PM, Daniel Povey <dp...@gm...> wrote:
>
>> No, it doesn't.  HTK supports that, but Kaldi doesn't because it's been
>> so long since people used those types of models.
>> Dan
>>
>>
>> On Tue, Feb 10, 2015 at 6:25 PM, Himanshu Joshi <hj...@us...> wrote:
>>
>>>  Does Kaldi support discrete acoustic models (where the acoustic input
>>> is a discrete symbol instead of an 39 dimensional real vector)? I want to
>>> make a Kaldi baseline that works on discrete/symbolic representations of
>>> the speech signal (MFCC filtered Cepstrum) to compare with a cognitive
>>> architecture based speech recognizer that cannot accept real values as
>>> inputs.
>>>
>>> Thanks,
>>> Himanshu
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Dive into the World of Parallel Programming. The Go Parallel Website,
>>> sponsored by Intel and developed in partnership with Slashdot Media, is
>>> your
>>> hub for all things parallel software development, from weekly thought
>>> leadership blogs to news, videos, case studies, tutorials and more. Take
>>> a
>>> look and join the conversation now. http://goparallel.sourceforge.net/
>>> _______________________________________________
>>> Kaldi-developers mailing list
>>> Kal...@li...
>>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>>
>>>
>>
>

Re: [Kaldi-developers] Discrete Symbol based acoustic models

[Himanshu J. <hj...@us...>]

Daniel,

 Thanks for your response. For now, I will try to work with HTK's VQ tool
and use symbolic inputs.

 One more question: Are you aware of any toolkits that implement the
A*/Stack Decoder, possibly with a PCFG assisted language model?

Thanks,
Himanshu

On Tue, Feb 10, 2015 at 3:52 PM, Daniel Povey <dp...@gm...> wrote:

> No, it doesn't.  HTK supports that, but Kaldi doesn't because it's been so
> long since people used those types of models.
> Dan
>
>
> On Tue, Feb 10, 2015 at 6:25 PM, Himanshu Joshi <hj...@us...> wrote:
>
>>  Does Kaldi support discrete acoustic models (where the acoustic input is
>> a discrete symbol instead of an 39 dimensional real vector)? I want to make
>> a Kaldi baseline that works on discrete/symbolic representations of the
>> speech signal (MFCC filtered Cepstrum) to compare with a cognitive
>> architecture based speech recognizer that cannot accept real values as
>> inputs.
>>
>> Thanks,
>> Himanshu
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Kaldi-developers mailing list
>> Kal...@li...
>> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>>
>>
>

Re: [Kaldi-developers] Discrete Symbol based acoustic models

[Daniel P. <dp...@gm...>]

No, it doesn't.  HTK supports that, but Kaldi doesn't because it's been so
long since people used those types of models.
Dan


On Tue, Feb 10, 2015 at 6:25 PM, Himanshu Joshi <hj...@us...> wrote:

>  Does Kaldi support discrete acoustic models (where the acoustic input is
> a discrete symbol instead of an 39 dimensional real vector)? I want to make
> a Kaldi baseline that works on discrete/symbolic representations of the
> speech signal (MFCC filtered Cepstrum) to compare with a cognitive
> architecture based speech recognizer that cannot accept real values as
> inputs.
>
> Thanks,
> Himanshu
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>

[Kaldi-developers] Discrete Symbol based acoustic models

[Himanshu J. <hj...@us...>]

 Does Kaldi support discrete acoustic models (where the acoustic input is a
discrete symbol instead of an 39 dimensional real vector)? I want to make a
Kaldi baseline that works on discrete/symbolic representations of the
speech signal (MFCC filtered Cepstrum) to compare with a cognitive
architecture based speech recognizer that cannot accept real values as
inputs.

Thanks,
Himanshu

Re: [Kaldi-developers] using KenLM?

[Tony R. <to...@ca...>]

It's very good in that it's both fast and compact - what more could you 
want!

IIRC it only does Modified KN, so if you want to prune your LMs (say for 
Kaldi G.fst) then it probably isn't what you are looking for.


Tony

On 02/07/2015 03:31 AM, Dan...@pa... wrote:
>
> Does anyone have experience with the KenLM language model? 
> https://kheafield.com/code/kenlm/
>
> Dan
>
>

-- 
** Cantab is hiring: www.cantabResearch.com/openings **
Dr A J Robinson, Founder, Cantab Research Ltd
Phone direct: 01223 778240 office: 01223 794497
Company reg no GB 05697423, VAT reg no 925606030
51 Canterbury Street, Cambridge, CB4 3QG, UK

[Kaldi-developers] using KenLM?

[<Dan...@pa...>]

Does anyone have experience with the KenLM language model?  https://kheafield.com/code/kenlm/

Dan

Re: [Kaldi-developers] Kaldi on Cygwin with OpenFST 1.4.1

[Daniel P. <dp...@gm...>]

>
>
> I am trying to compile Kaldi on Cygwin with the newer OpenFST 1.4.1.
> All the tools have been compiled (OpenFST with --enable-static
> --disable-shared, g++ version 4.8.3), but there seems to be a bug in the
> file trunk/src/makefiles/cygwin.mk:
>
> Instead of -enable-auto-import, it should be --enable-auto-import (two
> times mentioned in the file)
>
>
Please check that in!


> After fixing that, there seems to be some problems with the new C++11
> standard library, or some compile-time symbols seem not to be set correctly:
>
> kaldi-math.cc:52:33: error: ‘rand_r’ was not declared in this scope
>
> return rand_r(&(state->seed));
>

Possibly the relevant include statement was not done-- please see if you
can figure out what needs to be included.


>
> kaldi-matrix.cc:1327:49: error: there are no arguments to ‘strcasecmp’
> that depend on a template parameter, so a declaration of ‘strcasecmp’ must
> be available [-fpermissive]
>
> if (!KALDI_STRCASECMP(str.c_str(), "inf") ||
>

Again, this may be a question of not including the correct things- see if
you can figure it out.  But send a patch to me before you commit- I want to
check that these things are also available on other platforms.


> Do you know, which flags need to be set for Kaldi to compile?
>
> From previous runs, I already experienced, that for Kaldi to compile, I
> have to use the -O2 option, otherwise I get "too many sections" errors from
> the linker.
>
This is a Windows limitation.  Previously I think I had to break some files
up into smaller pieces to get around this problem.  Let me know which files
it's talking about.

Dan




>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Kaldi-developers mailing list
> Kal...@li...
> https://lists.sourceforge.net/lists/listinfo/kaldi-developers
>
>