Fwd: Re: Fwd: Re: merging mono files

Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 904 bytes --]

This is one recent instance where I described the structure of the 
folders. Perhaps I should have stated:

Each folder has a list of files + 3 /*sub*/folders, each with its own 
list of files.


On 12/12/2016 13:12, Dr. Mark Bugeja MD wrote:
> NB: each folder has a list of files + 3 folders, each with its own 
> list of files. Structure and names of L folders correspond to R folders. 



------------------------------------------------------------------------
Avast logo 
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
	

This email has been checked for viruses by Avast antivirus software.
www.avast.com 
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 





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

[-- Attachment #1.2: Type: text/html, Size: 2938 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-12 20:07, Dr. Mark Bugeja MD wrote:
> This is one recent instance where I described the structure of the
> folders. Perhaps I should have stated:
> 
> Each folder has a list of files + 3 /*sub*/folders, each with its own
> list of files.

Yes.

I assumed (from your original post) that there could be any number of 
sub-
folders, with arbitrary names, albeit (probably) all of form "rel" plus 
a
five digit number.

If those sub-folders are always present or at least are always meant to 
be
then (if I'd been writing a script for myself) I'd have checked that 
each
sample's folder contained the expected three sub-folders - no more and 
no
fewer.  But on the assumption that there could be any number of them, of
any name, I would have done what Kevin did, & made the script just 
process
whatever subfolders it found.

Also, your original example of file/folder layouts had quite a lot of 
"etc"s
in them, which implies that we weren't necessarily seeing the whole set 
of
possibilities.  And, your text said "Each subfolder has similarly names 
files
as shown.", which is too vague for anyone (writing a script) to be 
certain of
what you meant.

On the other hand, I do see - now - that your description, eg:

Basson16L
....rel00150
........036-C
........037-C#
........038-D
........etc
....rel00600
........036-C
........037-C#
........038-D
........etc
....rel99999
........036-C
........037-C#
........038-D
........etc
036-C
037-C#
038-D
  etc


did include separate files (the lines at the end of that list) as well 
as sub-
folders.  My only excuse for not realising their significance is that I 
thought
(wrongly!) that you'd forgotten to put lots of dots in front of one set 
of names!
On the other hand, there's no good reason to put the "main files" at the 
bottom
of a list.   They'd have been far more obvious if they'd been described 
first.


If I'd been describing this structure to someone else I'd have said 
something
like:

   For each set of samples, eg "Basson16" there's two folders named with 
"L"
   and "R" suffixes.  Each contains some audio files, one for each note 
of
   the scale, named accordingly, eg "037-C#.wav" - representing the C 
sharp
   that's the 37th note counted from the lowest pitched one in the sample
   set (or whatever the significance of that number is).

   As well as the main data for each note there's three additional files, 
each
   holding data describing short, medium and long 'releases'.  These are 
always
   stored in subfolders named "rel00150", "rel00600" and "rel99999".  
Whatever
   the set of main data files is, the subfolders should have the same 
named set
   of subsidiary files, so for example, as there's a 037-C#.wav file in 
the main
   folder there should be three more files with that name in the three 
relnnnnn
   folders.

   I would also have explained whether there could ever be any other 
files in the
   main or relnnnnn folders, which contain other things - eg any .txt 
files that
   contain descriptions of the data.

   Perhaps I'd also have said that all the individual files should have 
names that
   are a three digit number, a dash, and one of A A# B C C# D D# E F F# G 
G#.  I
   might have said what the range of the three-digit numbers is: do they 
always
   start at 001, and always end at the (same) high value?  Do they always 
go up in
   ones?  What should the script do if there's a gap in the sequence?


I'd then have listed the full names (paths) of all the files describing 
one note
for one sample eg:

   C:\my\organsamples\basson16l\037-C#.wav
   C:\my\organsamples\basson16l\rel00150\037-C#.wav
   C:\my\organsamples\basson16l\rel00600\037-C#.wav
   C:\my\organsamples\basson16l\rel99999\037-C#.wav

   C:\my\organsamples\basson16r\037-C#.wav
   C:\my\organsamples\basson16r\rel00150\037-C#.wav
   C:\my\organsamples\basson16r\rel00600\037-C#.wav
   C:\my\organsamples\basson16r\rel99999\037-C#.wav

which hopefully would have removed some of the vagueness.  Notice, no 
unnecessary
dots, and the full names (with the ".wav" extensions) of the files.


-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 4672 bytes --]

I have tested the wav samples. They won't load in the software 
GrandOrgue and give a PCM format error. Could this have something to do 
with the merging process we have just done?

Mark


On 13/12/2016 02:40, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-12 20:07, Dr. Mark Bugeja MD wrote:
>> This is one recent instance where I described the structure of the
>> folders. Perhaps I should have stated:
>>
>> Each folder has a list of files + 3 /*sub*/folders, each with its own
>> list of files.
> Yes.
>
> I assumed (from your original post) that there could be any number of
> sub-
> folders, with arbitrary names, albeit (probably) all of form "rel" plus
> a
> five digit number.
>
> If those sub-folders are always present or at least are always meant to
> be
> then (if I'd been writing a script for myself) I'd have checked that
> each
> sample's folder contained the expected three sub-folders - no more and
> no
> fewer.  But on the assumption that there could be any number of them, of
> any name, I would have done what Kevin did, & made the script just
> process
> whatever subfolders it found.
>
> Also, your original example of file/folder layouts had quite a lot of
> "etc"s
> in them, which implies that we weren't necessarily seeing the whole set
> of
> possibilities.  And, your text said "Each subfolder has similarly names
> files
> as shown.", which is too vague for anyone (writing a script) to be
> certain of
> what you meant.
>
> On the other hand, I do see - now - that your description, eg:
>
> Basson16L
> ....rel00150
> ........036-C
> ........037-C#
> ........038-D
> ........etc
> ....rel00600
> ........036-C
> ........037-C#
> ........038-D
> ........etc
> ....rel99999
> ........036-C
> ........037-C#
> ........038-D
> ........etc
> 036-C
> 037-C#
> 038-D
>    etc
>
>
> did include separate files (the lines at the end of that list) as well
> as sub-
> folders.  My only excuse for not realising their significance is that I
> thought
> (wrongly!) that you'd forgotten to put lots of dots in front of one set
> of names!
> On the other hand, there's no good reason to put the "main files" at the
> bottom
> of a list.   They'd have been far more obvious if they'd been described
> first.
>
>
> If I'd been describing this structure to someone else I'd have said
> something
> like:
>
>     For each set of samples, eg "Basson16" there's two folders named with
> "L"
>     and "R" suffixes.  Each contains some audio files, one for each note
> of
>     the scale, named accordingly, eg "037-C#.wav" - representing the C
> sharp
>     that's the 37th note counted from the lowest pitched one in the sample
>     set (or whatever the significance of that number is).
>
>     As well as the main data for each note there's three additional files,
> each
>     holding data describing short, medium and long 'releases'.  These are
> always
>     stored in subfolders named "rel00150", "rel00600" and "rel99999".
> Whatever
>     the set of main data files is, the subfolders should have the same
> named set
>     of subsidiary files, so for example, as there's a 037-C#.wav file in
> the main
>     folder there should be three more files with that name in the three
> relnnnnn
>     folders.
>
>     I would also have explained whether there could ever be any other
> files in the
>     main or relnnnnn folders, which contain other things - eg any .txt
> files that
>     contain descriptions of the data.
>
>     Perhaps I'd also have said that all the individual files should have
> names that
>     are a three digit number, a dash, and one of A A# B C C# D D# E F F# G
> G#.  I
>     might have said what the range of the three-digit numbers is: do they
> always
>     start at 001, and always end at the (same) high value?  Do they always
> go up in
>     ones?  What should the script do if there's a gap in the sequence?
>
>
> I'd then have listed the full names (paths) of all the files describing
> one note
> for one sample eg:
>
>     C:\my\organsamples\basson16l\037-C#.wav
>     C:\my\organsamples\basson16l\rel00150\037-C#.wav
>     C:\my\organsamples\basson16l\rel00600\037-C#.wav
>     C:\my\organsamples\basson16l\rel99999\037-C#.wav
>
>     C:\my\organsamples\basson16r\037-C#.wav
>     C:\my\organsamples\basson16r\rel00150\037-C#.wav
>     C:\my\organsamples\basson16r\rel00600\037-C#.wav
>     C:\my\organsamples\basson16r\rel99999\037-C#.wav
>
> which hopefully would have removed some of the vagueness.  Notice, no
> unnecessary
> dots, and the full names (with the ".wav" extensions) of the files.
>
>



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

[-- Attachment #1.2: Type: text/html, Size: 5750 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-13 18:39, Dr. Mark Bugeja MD wrote:
> I have tested the wav samples. They won't load in the software
> GrandOrgue and give a PCM format error. Could this have something to
> do with the merging process we have just done?

Who knows?

I had the impression you earlier tested a merge and decided the 
resulting file
was ok (either it sounded ok, or it looked ok in some other program)?  
Was that
so?

If so, do the files merged by the script also sound ok to you, or look 
ok, doing
whatever it was that you did before to check a file?



Take one example (ie a left file, a right file and file that was merged 
from them),
and for each of those files issue in a command window this command 
(though use the
paths that make sense on your computer):

  "C:\path\to\sox\soxi.exe" "C:\path\to\audio-files\some.wav"

Note that this runs "soxi.exe" not "sox.exe".  Make sure that you have a 
soxi.exe
(in the same place as you have sox.exe).

Paste the command you issued and whatever the result was, for each file, 
in your
next reply.

Also issue, for each file, this command:

  "C:\path\to\sox\sox.exe" "C:\path\to\audio-files\some.wav" -n stat 
stats

and paste those commands and results into your reply too.  Note that 
this command
called 'sox' not 'soxi', and the 'stat stats' part runs two separate 
effects which
will list details about the audio data in the file concerned.


So, that's three separate commands to be issued, against three separate 
files.
Hopefully something in the details the three commands list will give 
someone here a
clue as to what might be wrong.


Do you remember earlier in the discussion someone pointed out that, 
really, scripts
should check things?  The script you've been running checks nothing.

-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 2877 bytes --]

Hi,

I can only test the files in GrandOrgue when I build the organ in 
question. I cannot test individual files on the software. I did check 
files with iZotope and they look good visually, sound well when played, 
they are in 24 bit and 48kHz sample rate, they load up on 
LoopAuditioneer so I could add pitch information and loops.

The only other software that issued a warning was Sony's Soundforge... 
though I can't get this warning again for some reason. What I am 
noticing just now is that Soundforge gives a detail (property) when 
opening up a file, something that I did not observe before, not that it 
means anything to me:

  * Rgns/Play/Cmd: No/No/No

A file that is known to work with GrandOrgue gives _*
*_

  * Rgns/Play/Cmd:_*Yes*_/No/No.

Could my answer lie with this difference?

I'll try running the script as you recommended and generate the "logs".

Mark


On 14/12/2016 00:48, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-13 18:39, Dr. Mark Bugeja MD wrote:
>> I have tested the wav samples. They won't load in the software
>> GrandOrgue and give a PCM format error. Could this have something to
>> do with the merging process we have just done?
> Who knows?
>
> I had the impression you earlier tested a merge and decided the
> resulting file
> was ok (either it sounded ok, or it looked ok in some other program)?
> Was that
> so?
>
> If so, do the files merged by the script also sound ok to you, or look
> ok, doing
> whatever it was that you did before to check a file?
>
>
>
> Take one example (ie a left file, a right file and file that was merged
> from them),
> and for each of those files issue in a command window this command
> (though use the
> paths that make sense on your computer):
>
>    "C:\path\to\sox\soxi.exe" "C:\path\to\audio-files\some.wav"
>
> Note that this runs "soxi.exe" not "sox.exe".  Make sure that you have a
> soxi.exe
> (in the same place as you have sox.exe).
>
> Paste the command you issued and whatever the result was, for each file,
> in your
> next reply.
>
> Also issue, for each file, this command:
>
>    "C:\path\to\sox\sox.exe" "C:\path\to\audio-files\some.wav" -n stat
> stats
>
> and paste those commands and results into your reply too.  Note that
> this command
> called 'sox' not 'soxi', and the 'stat stats' part runs two separate
> effects which
> will list details about the audio data in the file concerned.
>
>
> So, that's three separate commands to be issued, against three separate
> files.
> Hopefully something in the details the three commands list will give
> someone here a
> clue as to what might be wrong.
>
>
> Do you remember earlier in the discussion someone pointed out that,
> really, scripts
> should check things?  The script you've been running checks nothing.
>



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

[-- Attachment #1.2: Type: text/html, Size: 4630 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-14 07:22, Dr. Mark Bugeja MD wrote:
> Hi,
> 
> I can only test the files in GrandOrgue when I build the organ in
> question. I cannot test individual files on the software. I did check
> files with iZotope and they look good visually, sound well when
> played, they are in 24 bit and 48kHz sample rate, they load up on
> LoopAuditioneer so I could add pitch information and loops.
> 
> The only other software that issued a warning was Sony's Soundforge...
> though I can't get this warning again for some reason. What I am
> noticing just now is that Soundforge gives a detail (property) when
> opening up a file, something that I did not observe before, not that
> it means anything to me:
> 
>  * Rgns/Play/Cmd: No/No/No
> 
> A file that is known to work with GrandOrgue gives _*
> *_
> 
>  * Rgns/Play/Cmd:_*Yes*_/No/No.
> 
> Could my answer lie with this difference?

I've no idea what that means.  However: http://www.magix-audio.com who 
took over the
Sony products do have technical support (I know this because I emailed 
them several
times fairly recently about one of their other products), so you could 
email them and
ask what that means.

-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 2937 bytes --]

Would it help to provide 2 samples, one from an instrument known to work 
and another, a file merged with the script? I have no idea how to 
compare them other than opening them up in a software like soundforge 
and seeing what the properties of each show? It seems there is some kind 
of information within these files (?header) that is relied upon by 
GrandOrgue and needs to be somehow corrected. Otherwise the merged files 
are what they ought to be - stereo, 24bit and 48kHz.

If this can help before I go through with anything else then here is the 
link:

https://mega.nz/#!IZQwFByQ!oZCDk6Qh_xSq_DvC3mKBJCVRO726cvAFCULMHWFNhNY

The files are clearly labelled as to which is which.

If there is something in them, can it be corrected manually or (less 
preferably) by re-doing the merger using a modified script to preserve 
as much of the properties of the original (source) files?

Mark

______________________________________________
On 14/12/2016 00:48, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-13 18:39, Dr. Mark Bugeja MD wrote:
>> I have tested the wav samples. They won't load in the software
>> GrandOrgue and give a PCM format error. Could this have something to
>> do with the merging process we have just done?
> Who knows?
>
> I had the impression you earlier tested a merge and decided the
> resulting file
> was ok (either it sounded ok, or it looked ok in some other program)?
> Was that
> so?
>
> If so, do the files merged by the script also sound ok to you, or look
> ok, doing
> whatever it was that you did before to check a file?
>
>
>
> Take one example (ie a left file, a right file and file that was merged
> from them),
> and for each of those files issue in a command window this command
> (though use the
> paths that make sense on your computer):
>
>    "C:\path\to\sox\soxi.exe" "C:\path\to\audio-files\some.wav"
>
> Note that this runs "soxi.exe" not "sox.exe".  Make sure that you have a
> soxi.exe
> (in the same place as you have sox.exe).
>
> Paste the command you issued and whatever the result was, for each file,
> in your
> next reply.
>
> Also issue, for each file, this command:
>
>    "C:\path\to\sox\sox.exe" "C:\path\to\audio-files\some.wav" -n stat
> stats
>
> and paste those commands and results into your reply too.  Note that
> this command
> called 'sox' not 'soxi', and the 'stat stats' part runs two separate
> effects which
> will list details about the audio data in the file concerned.
>
>
> So, that's three separate commands to be issued, against three separate
> files.
> Hopefully something in the details the three commands list will give
> someone here a
> clue as to what might be wrong.
>
>
> Do you remember earlier in the discussion someone pointed out that,
> really, scripts
> should check things?  The script you've been running checks nothing.
>



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

[-- Attachment #1.2: Type: text/html, Size: 4901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-14 09:50, Dr. Mark Bugeja MD wrote:
> Would it help to provide 2 samples, one from an instrument known to
> work and another, a file merged with the script?

It might.

> I have no idea how to compare them other than opening them up in a
> software like soundforge and seeing what the properties of each show?

The soxi, and sox stat stats commands are going to tell us a whole load
of things about each file.  They might or might not be helpful... but
let's see what they say.


> If there is something in them, can it be corrected manually or (less
> preferably) by re-doing the merger using a modified script to preserve
> as much of the properties of the original (source) files?

Maybe; sox has lots of options but we need to know what the problem is
first.


-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-14 09:50, Dr. Mark Bugeja MD wrote:
> Would it help to provide 2 samples, one from an instrument known to
> work and another, a file merged with the script? I have no idea how to
> compare them other than opening them up in a software like soundforge
> and seeing what the properties of each show? It seems there is some
> kind of information within these files (?header) that is relied upon
> by GrandOrgue and needs to be somehow corrected. Otherwise the merged
> files are what they ought to be - stereo, 24bit and 48kHz.
> 
> If this can help before I go through with anything else then here is 
> the link:
> 
> https://mega.nz/#!IZQwFByQ!oZCDk6Qh_xSq_DvC3mKBJCVRO726cvAFCULMHWFNhNY
> 
> The files are clearly labelled as to which is which.

Can you:
   - make a safety copy of the seems-ok stereo file so the original one 
does
     not get changed


   - make a reverse stereo copy of it (ie the audio data should remain 
the same
     but left will be on the right, and right on the left), by:

     C:\>"path\to\sox\sox.exe" "seems-ok-file.wav" 
"seems-ok-reversed.wav" remix 2 1


   - then find out if the reversed by sox seems-ok file can load into SO 
without
     an error

   - then re-reverse it, so

     C:\>"path\to\sox\sox.exe" "seems-ok-reversed.wav" 
"seems-ok-reversedagain.wav" remix 2 1

     and test that (which should audio-wise) be the same as the original 
one.


Can you then put the reversed and reversedagain files online somewhere 
for me to download.


I'm sorry, but I think it won't be until later tonight before I have an 
opportunity to look
at this in more detail.

-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 2696 bytes --]

Hi, I have asked a GrandOrgue guru who has helped many times in the past 
and himself a sampleset creator. I sent him my main files and releases 
and he discovered that the issue lies in the fact with the releases, in 
that, for some strange mysterious reason, are saved as "Wave_ 
Format_Extensible (Wavex)" whilst the main files are in 
"Wave_Format_PCM". The latter is the correct format. This is the first 
time I ever came across this. I am still waiting for a reply as to how 
he managed to extract this information!

Now for the next step: it's not so much understanding what Wavex is but 
what software sports and supports this feature. All software I have used 
so far identify one type of wav format only. No choice. No options to 
select other than other formats like aiff, aa3, ac3, vox, wma, wmv, mp3, 
flac, ogg, etc etc!

Mark


On 15/12/2016 10:31, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-14 09:50, Dr. Mark Bugeja MD wrote:
>> Would it help to provide 2 samples, one from an instrument known to
>> work and another, a file merged with the script? I have no idea how to
>> compare them other than opening them up in a software like soundforge
>> and seeing what the properties of each show? It seems there is some
>> kind of information within these files (?header) that is relied upon
>> by GrandOrgue and needs to be somehow corrected. Otherwise the merged
>> files are what they ought to be - stereo, 24bit and 48kHz.
>>
>> If this can help before I go through with anything else then here is
>> the link:
>>
>> https://mega.nz/#!IZQwFByQ!oZCDk6Qh_xSq_DvC3mKBJCVRO726cvAFCULMHWFNhNY
>>
>> The files are clearly labelled as to which is which.
> Can you:
>     - make a safety copy of the seems-ok stereo file so the original one
> does
>       not get changed
>
>
>     - make a reverse stereo copy of it (ie the audio data should remain
> the same
>       but left will be on the right, and right on the left), by:
>
>       C:\>"path\to\sox\sox.exe" "seems-ok-file.wav"
> "seems-ok-reversed.wav" remix 2 1
>
>
>     - then find out if the reversed by sox seems-ok file can load into SO
> without
>       an error
>
>     - then re-reverse it, so
>
>       C:\>"path\to\sox\sox.exe" "seems-ok-reversed.wav"
> "seems-ok-reversedagain.wav" remix 2 1
>
>       and test that (which should audio-wise) be the same as the original
> one.
>
>
> Can you then put the reversed and reversedagain files online somewhere
> for me to download.
>
>
> I'm sorry, but I think it won't be until later tonight before I have an
> opportunity to look
> at this in more detail.
>



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

[-- Attachment #1.2: Type: text/html, Size: 4159 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-15 10:18, Dr. Mark Bugeja MD wrote:
> Hi, I have asked a GrandOrgue guru who has helped many times in the
> past and himself a sampleset creator. I sent him my main files and
> releases and he discovered that the issue lies in the fact with the
> releases, in that, for some strange mysterious reason, are saved as
> "Wave_ Format_Extensible (Wavex)" whilst the main files are in
> "Wave_Format_PCM". The latter is the correct format. This is the first
> time I ever came across this. I am still waiting for a reply as to how
> he managed to extract this information!
> 
> Now for the next step: it's not so much understanding what Wavex is
> but what software sports and supports this feature. All software I
> have used so far identify one type of wav format only. No choice. No
> options to select other than other formats like aiff, aa3, ac3, vox,
> wma, wmv, mp3, flac, ogg, etc etc!

The .wav file format is what, in computing, is known as a 'container'
file.  There are many types of data that can appear inside one, defined
by the initial few bytes in the header of the file.  For a simple WAVE
file there's just the header then the audio data, but - I believe - more
complicated files can have non-audio data interleaved with audio data
throughout the file.  Each section of audio or other data is introduced
by something saying what follows, so programs can skip over the parts
they do not understand.

For example, a Broadcast Wave file also has extension .wav, but contains
extra non-audio data required by the BBC, EBU and so on.


Sox does support reading and creation of files whose names end in .wav
but have (as the sox manual says) non-standard internal headers; there
are extra parameters for sox commands that will allow us to tell it what
form an input file has and what form the output file needs to have.

I'm curious though why soxi did not identify the difference.  Maybe it's
not aware of the difference, or, the example files you've looked at with
soxi weren't different.  Did you send to the guru the same files as 
those
that you've been issuing commands against?

Also, if this is the problem, what you wrote implies that the funny 
format
is only for release files... which would imply that the sox merge of the
main files should have worked.  Did they?


-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 3589 bytes --]

I don't recall exactly what I sent to this forum though I may have sent 
only the main file because I suspect this was at fault. I sent my GO 
colleague a whole batch of files including the releases I later 
suspected to be the real issue and he confirmed they were. I now used 
Sony's Soundforge to batch process one set of release files and sent him 
a specimen to check if the issue has indeed been addressed by what I did.

How these files turned out so different I have no idea and the person 
who would have been able to answer the question is no longer with us to 
do so. So we've got to sort out what he left behind the best way 
possible. If the batch process I chose ie bit-depth converter, selecting 
24 bit instead of the default 32 that shows up on the window, works fine 
then the matter is solved and another lesson learnt.

For all its worth, this is the link to sample problem file (one of the 
releases that is being implicated and yet to be corrected):

https://mega.nz/#!pNAUmAgD!I0sh9C29SpFF7iMnf-0P4FvkfhQdqyawK5a0XMxf3DI

Regards

Mark


On 15/12/2016 12:31, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-15 10:18, Dr. Mark Bugeja MD wrote:
>> Hi, I have asked a GrandOrgue guru who has helped many times in the
>> past and himself a sampleset creator. I sent him my main files and
>> releases and he discovered that the issue lies in the fact with the
>> releases, in that, for some strange mysterious reason, are saved as
>> "Wave_ Format_Extensible (Wavex)" whilst the main files are in
>> "Wave_Format_PCM". The latter is the correct format. This is the first
>> time I ever came across this. I am still waiting for a reply as to how
>> he managed to extract this information!
>>
>> Now for the next step: it's not so much understanding what Wavex is
>> but what software sports and supports this feature. All software I
>> have used so far identify one type of wav format only. No choice. No
>> options to select other than other formats like aiff, aa3, ac3, vox,
>> wma, wmv, mp3, flac, ogg, etc etc!
> The .wav file format is what, in computing, is known as a 'container'
> file.  There are many types of data that can appear inside one, defined
> by the initial few bytes in the header of the file.  For a simple WAVE
> file there's just the header then the audio data, but - I believe - more
> complicated files can have non-audio data interleaved with audio data
> throughout the file.  Each section of audio or other data is introduced
> by something saying what follows, so programs can skip over the parts
> they do not understand.
>
> For example, a Broadcast Wave file also has extension .wav, but contains
> extra non-audio data required by the BBC, EBU and so on.
>
>
> Sox does support reading and creation of files whose names end in .wav
> but have (as the sox manual says) non-standard internal headers; there
> are extra parameters for sox commands that will allow us to tell it what
> form an input file has and what form the output file needs to have.
>
> I'm curious though why soxi did not identify the difference.  Maybe it's
> not aware of the difference, or, the example files you've looked at with
> soxi weren't different.  Did you send to the guru the same files as
> those
> that you've been issuing commands against?
>
> Also, if this is the problem, what you wrote implies that the funny
> format
> is only for release files... which would imply that the sox merge of the
> main files should have worked.  Did they?
>
>



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

[-- Attachment #1.2: Type: text/html, Size: 5661 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 4328 bytes --]

It seems like what I did didn't work although I'm still waiting for a 
reply from my friend.

I am looking for converters hoping to strike gold but instead I seem to 
find myself sinking deeper and deeper in thick mud.

For instance.... there is this online converter. Ok. Select 
bit-resolution, done; sampling rate, done; audio channels, done. Then... 
show advanced options, PCM format: and a horrible list with such things 
as little-endian and big-endian crops up. What the.......! What are 
these? A new race? Aliens from outer space?

http://audio.online-convert.com/convert-to-wav

Mark


On 15/12/2016 15:20, Dr. Mark Bugeja MD wrote:
>
> I don't recall exactly what I sent to this forum though I may have 
> sent only the main file because I suspect this was at fault. I sent my 
> GO colleague a whole batch of files including the releases I later 
> suspected to be the real issue and he confirmed they were. I now used 
> Sony's Soundforge to batch process one set of release files and sent 
> him a specimen to check if the issue has indeed been addressed by what 
> I did.
>
> How these files turned out so different I have no idea and the person 
> who would have been able to answer the question is no longer with us 
> to do so. So we've got to sort out what he left behind the best way 
> possible. If the batch process I chose ie bit-depth converter, 
> selecting 24 bit instead of the default 32 that shows up on the 
> window, works fine then the matter is solved and another lesson learnt.
>
> For all its worth, this is the link to sample problem file (one of the 
> releases that is being implicated and yet to be corrected):
>
> https://mega.nz/#!pNAUmAgD!I0sh9C29SpFF7iMnf-0P4FvkfhQdqyawK5a0XMxf3DI
>
> Regards
>
> Mark
>
>
> On 15/12/2016 12:31, Jeremy Nicoll - ml sox users wrote:
>> On 2016-12-15 10:18, Dr. Mark Bugeja MD wrote:
>>> Hi, I have asked a GrandOrgue guru who has helped many times in the
>>> past and himself a sampleset creator. I sent him my main files and
>>> releases and he discovered that the issue lies in the fact with the
>>> releases, in that, for some strange mysterious reason, are saved as
>>> "Wave_ Format_Extensible (Wavex)" whilst the main files are in
>>> "Wave_Format_PCM". The latter is the correct format. This is the first
>>> time I ever came across this. I am still waiting for a reply as to how
>>> he managed to extract this information!
>>>
>>> Now for the next step: it's not so much understanding what Wavex is
>>> but what software sports and supports this feature. All software I
>>> have used so far identify one type of wav format only. No choice. No
>>> options to select other than other formats like aiff, aa3, ac3, vox,
>>> wma, wmv, mp3, flac, ogg, etc etc!
>> The .wav file format is what, in computing, is known as a 'container'
>> file.  There are many types of data that can appear inside one, defined
>> by the initial few bytes in the header of the file.  For a simple WAVE
>> file there's just the header then the audio data, but - I believe - more
>> complicated files can have non-audio data interleaved with audio data
>> throughout the file.  Each section of audio or other data is introduced
>> by something saying what follows, so programs can skip over the parts
>> they do not understand.
>>
>> For example, a Broadcast Wave file also has extension .wav, but contains
>> extra non-audio data required by the BBC, EBU and so on.
>>
>>
>> Sox does support reading and creation of files whose names end in .wav
>> but have (as the sox manual says) non-standard internal headers; there
>> are extra parameters for sox commands that will allow us to tell it what
>> form an input file has and what form the output file needs to have.
>>
>> I'm curious though why soxi did not identify the difference.  Maybe it's
>> not aware of the difference, or, the example files you've looked at with
>> soxi weren't different.  Did you send to the guru the same files as
>> those
>> that you've been issuing commands against?
>>
>> Also, if this is the problem, what you wrote implies that the funny
>> format
>> is only for release files... which would imply that the sox merge of the
>> main files should have worked.  Did they?
>>
>>
>



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

[-- Attachment #1.2: Type: text/html, Size: 7066 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-15 16:46, Dr. Mark Bugeja MD wrote:
> It seems like what I did didn't work although I'm still waiting for a
> reply from my friend.
> 
> I am looking for converters hoping to strike gold but instead I seem
> to find myself sinking deeper and deeper in thick mud.
> 
> For instance.... there is this online converter. Ok. Select
> bit-resolution, done; sampling rate, done; audio channels, done.
> Then... show advanced options, PCM format: and a horrible list with
> such things as little-endian and big-endian crops up. What the.......!
> What are these? A new race? Aliens from outer space?

When a 24-bit sample value is stored in a file, its three bytes can be
in one order or the reverse; little-endian / big-endian are names for
one or the other option.

The thing that's so far stopped me from suggesting revisions of the sox
command that creates merged files is that I don't know whether it has to
include parameters telling sox what internal format the input file has,
as well as which internal format you want the result to be.  I'd have
hoped sox can id he input format... but if soxi can't discriminate
between the two formats of data then maybe sox also cannot.

There's also, maybe, a problem if it turns out that only some of your
release files are in this funny format.  The script that does merging
may have to become quite a lot more complicated - it's easy to have it
issue one command for 'main' files and another for 'release' files, but
complicated if it has to somehow test which format files are in.




> http://audio.online-convert.com/convert-to-wav

If you were going to use an online converter you'd need some sort of
script, I expect, to feed thousands of files into it and retrieve the
result - it'd be awful doing that manually.  I'm not keen on trying to
write a script for that if I don't have to.

-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 2375 bytes --]

The format needed by GrandOrgue (GO) is wav, 24 bit, 48kHz, PCM. When I 
use audio editors, this is what the files seem to show so I don't even 
know why they need converting in the first place even with the knowledge 
that the current wav format is "extensible" :-/ and not acceptable/ 
recognized by GO.

Mark

On 15/12/2016 18:42, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-15 16:46, Dr. Mark Bugeja MD wrote:
>> It seems like what I did didn't work although I'm still waiting for a
>> reply from my friend.
>>
>> I am looking for converters hoping to strike gold but instead I seem
>> to find myself sinking deeper and deeper in thick mud.
>>
>> For instance.... there is this online converter. Ok. Select
>> bit-resolution, done; sampling rate, done; audio channels, done.
>> Then... show advanced options, PCM format: and a horrible list with
>> such things as little-endian and big-endian crops up. What the.......!
>> What are these? A new race? Aliens from outer space?
> When a 24-bit sample value is stored in a file, its three bytes can be
> in one order or the reverse; little-endian / big-endian are names for
> one or the other option.
>
> The thing that's so far stopped me from suggesting revisions of the sox
> command that creates merged files is that I don't know whether it has to
> include parameters telling sox what internal format the input file has,
> as well as which internal format you want the result to be.  I'd have
> hoped sox can id he input format... but if soxi can't discriminate
> between the two formats of data then maybe sox also cannot.
>
> There's also, maybe, a problem if it turns out that only some of your
> release files are in this funny format.  The script that does merging
> may have to become quite a lot more complicated - it's easy to have it
> issue one command for 'main' files and another for 'release' files, but
> complicated if it has to somehow test which format files are in.
>
>
>
>
>> http://audio.online-convert.com/convert-to-wav
> If you were going to use an online converter you'd need some sort of
> script, I expect, to feed thousands of files into it and retrieve the
> result - it'd be awful doing that manually.  I'm not keen on trying to
> write a script for that if I don't have to.
>



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

[-- Attachment #1.2: Type: text/html, Size: 3790 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 2737 bytes --]

Hurrah!!!!!! I found /*AudioMove*/ amongst my programs and it worked 
beautifully converting all my releases in less than 3 minutes all 1611 
files!

I got to the organ to load at long last. There are some errors but these 
are related to tuning mostly, something I find with a lot of instruments 
that have not had the samples processed properly.

So Mission Accomplished (well - almost)..... definitely from the merging 
point of view.

Thanks to all, especially you Jeremy, once again.... and whoever created 
this marvellous piece of software. It sure saved my day.

Keep this bit of software amongst your arsenal if ever you need to do 
conversion jobs like this!

Mark
On 15/12/2016 18:42, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-15 16:46, Dr. Mark Bugeja MD wrote:
>> It seems like what I did didn't work although I'm still waiting for a
>> reply from my friend.
>>
>> I am looking for converters hoping to strike gold but instead I seem
>> to find myself sinking deeper and deeper in thick mud.
>>
>> For instance.... there is this online converter. Ok. Select
>> bit-resolution, done; sampling rate, done; audio channels, done.
>> Then... show advanced options, PCM format: and a horrible list with
>> such things as little-endian and big-endian crops up. What the.......!
>> What are these? A new race? Aliens from outer space?
> When a 24-bit sample value is stored in a file, its three bytes can be
> in one order or the reverse; little-endian / big-endian are names for
> one or the other option.
>
> The thing that's so far stopped me from suggesting revisions of the sox
> command that creates merged files is that I don't know whether it has to
> include parameters telling sox what internal format the input file has,
> as well as which internal format you want the result to be.  I'd have
> hoped sox can id he input format... but if soxi can't discriminate
> between the two formats of data then maybe sox also cannot.
>
> There's also, maybe, a problem if it turns out that only some of your
> release files are in this funny format.  The script that does merging
> may have to become quite a lot more complicated - it's easy to have it
> issue one command for 'main' files and another for 'release' files, but
> complicated if it has to somehow test which format files are in.
>
>
>
>
>> http://audio.online-convert.com/convert-to-wav
> If you were going to use an online converter you'd need some sort of
> script, I expect, to feed thousands of files into it and retrieve the
> result - it'd be awful doing that manually.  I'm not keen on trying to
> write a script for that if I don't have to.
>



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

[-- Attachment #1.2: Type: text/html, Size: 4189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-16 02:47, Dr. Mark Bugeja MD wrote:
> Hurrah!!!!!! I found /*AudioMove*/ amongst my programs and it worked
> beautifully converting all my releases in less than 3 minutes all 1611
> files!

I take it you mean: https://public.msli.com/lcs/audiomove/ ?

That looks useful, especially as I see that apart from its use via a 
GUI, it can be
controlled from 'the commandline' so scripts can use it if they wish to.

I guess you're probably happier with GUI-based tools, but one of the big 
reasons why
I like commandline (or CLI as it's often abbreviated, meaning Command 
Line Interface)
tools is that by keeping a copy of the commands I used to do something, 
I implicitly
get full documentation of the processes I went through.

It's much harder to write "what I did" notes if you have to describe 
what you clicked
on and where you dragged things...  As I learn more about manipulating 
audio files on
a computer (I have been making location recordings, mainly of classical 
music, for
almost 40 years) I sometimes want to go back to recordings I worked on 
before and try
to manipulate them differently from last time.  I need the detailed 
notes to know how
I did it last time (& indeed I also have detailed notes about venues, eg 
how I placed
mics, which mics I used, why I chose them, what I think I could do 
better next time I
record in that place, and so on).

Computer-wise I do have the advantage of a degree in Computing & a 
working life spent
programming things, but none of that was audio or on PCs.



> So Mission Accomplished (well - almost)..... definitely from the
> merging point of view.
> 
> Thanks to all, especially you Jeremy, once again.... and whoever
> created this marvellous piece of software. It sure saved my day.

It was a pleasure.


One last, small thing.  You might notice that when I reply to you I 
usually
chop out of my reply stuff that needn't be there.  You'll see that most 
of
us do that.  If you keep posting here, it would be good if you did the 
same.

For example, I've deleted all of the copy of my original email that you 
quoted,
because I already know what I wrote earlier and so does anyone else who 
is
reading this conversation.


-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 366 bytes --]

I shall! ;-)

Regards
Mark

On 16/12/2016 10:46, Jeremy Nicoll - ml sox users wrote:
> One last, small thing.  You might notice that when I reply to you I
> usually
> chop out of my reply stuff that needn't be there.  You'll see that most
> of
> us do that.



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

[-- Attachment #1.2: Type: text/html, Size: 1528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 2041 bytes --]

There is no such soxi.exe in the sox folder!


On 14/12/2016 00:48, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-13 18:39, Dr. Mark Bugeja MD wrote:
>> I have tested the wav samples. They won't load in the software
>> GrandOrgue and give a PCM format error. Could this have something to
>> do with the merging process we have just done?
> Who knows?
>
> I had the impression you earlier tested a merge and decided the
> resulting file
> was ok (either it sounded ok, or it looked ok in some other program)?
> Was that
> so?
>
> If so, do the files merged by the script also sound ok to you, or look
> ok, doing
> whatever it was that you did before to check a file?
>
>
>
> Take one example (ie a left file, a right file and file that was merged
> from them),
> and for each of those files issue in a command window this command
> (though use the
> paths that make sense on your computer):
>
>    "C:\path\to\sox\soxi.exe" "C:\path\to\audio-files\some.wav"
>
> Note that this runs "soxi.exe" not "sox.exe".  Make sure that you have a
> soxi.exe
> (in the same place as you have sox.exe).
>
> Paste the command you issued and whatever the result was, for each file,
> in your
> next reply.
>
> Also issue, for each file, this command:
>
>    "C:\path\to\sox\sox.exe" "C:\path\to\audio-files\some.wav" -n stat
> stats
>
> and paste those commands and results into your reply too.  Note that
> this command
> called 'sox' not 'soxi', and the 'stat stats' part runs two separate
> effects which
> will list details about the audio data in the file concerned.
>
>
> So, that's three separate commands to be issued, against three separate
> files.
> Hopefully something in the details the three commands list will give
> someone here a
> clue as to what might be wrong.
>
>
> Do you remember earlier in the discussion someone pointed out that,
> really, scripts
> should check things?  The script you've been running checks nothing.
>



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

[-- Attachment #1.2: Type: text/html, Size: 3213 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-14 13:02, Dr. Mark Bugeja MD wrote:
> There is no such soxi.exe in the sox folder!

Oops, you clearly didn't read the install notes, did you?

Just make a copy of sox.exe and name that soxi.exe;   this works because
when you then use the soxi.exe copy, the program examines the name under
which it was called and does different things.

This is not something that all utility programs always do; it's a 
special
trick in the way that sox/soxi (and also play.exe and rec.exe if you 
make
copies with those names) work.

-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 1008 bytes --]

installation notes.... no; most times, accompanying notes tend to 
confuse me more than they help. But my mistake.... I should have at 
least tried. I'll do so after I send this message

I tried running the sequence using edited combine.vbs. All I got were 4 
empty folders.

Regards

Mark


On 14/12/2016 14:29, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-14 13:02, Dr. Mark Bugeja MD wrote:
>> There is no such soxi.exe in the sox folder!
> Oops, you clearly didn't read the install notes, did you?
>
> Just make a copy of sox.exe and name that soxi.exe;   this works because
> when you then use the soxi.exe copy, the program examines the name under
> which it was called and does different things.
>
> This is not something that all utility programs always do; it's a
> special
> trick in the way that sox/soxi (and also play.exe and rec.exe if you
> make
> copies with those names) work.
>



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

[-- Attachment #1.2: Type: text/html, Size: 2401 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-14 14:05, Dr. Mark Bugeja MD wrote:
> installation notes.... no; most times, accompanying notes tend to
> confuse me more than they help. But my mistake.... I should have at
> least tried. I'll do so after I send this message
> 
> I tried running the sequence using edited combine.vbs. All I got were
> 4 empty folders.

Sequence?  Do you mean the soxi and sox commands?

If you do, it's got nothing to do with combine.vbs; it's a pair of 
commands
you need to issue, from a command window, against (I suggested) one set 
of
files - the left, right and stereo files that had the error.

As you said it could be worth also issuing them for a valid stereo file

Remember what I said about not having to retype every command in the 
command
window too: type the soxi command in once & execute it.  Then slightly 
change
it to affect three other files, one by one & issue those.

Then revise it to be the sox command against one of the files & issue 
it. Then
revise that 3 times for the other three files.

Paste all of the commands & results into an email.

-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 754 bytes --]

There is no instruction to make a copy of sox,exe and to rename it as 
soxi.exe

:-P

Having said that do I run it using the combine.vbs or directly in cmd 
prompt?

Mark


On 14/12/2016 00:48, Jeremy Nicoll - ml sox users wrote:
> Take one example (ie a left file, a right file and file that was merged
> from them),
> and for each of those files issue in a command window this command
> (though use the
> paths that make sense on your computer):
>
>    "C:\path\to\sox\soxi.exe" "C:\path\to\audio-files\some.wav"
>
> Note that this runs "soxi.exe" not "sox.exe".  Make sure that you have a
> soxi.exe
> (in the same place as you have sox.exe).



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

[-- Attachment #1.2: Type: text/html, Size: 2018 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-14 13:58, Dr. Mark Bugeja MD wrote:
> There is no instruction to make a copy of sox,exe and to rename it as 
> soxi.exe
> 
> :-P

There is in the download zip for sox that I have, in file: 
README.win32.txt

-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 921 bytes --]

my replies are no getting through. The amount of text is making the 
files too big. This list is so frustrating. Other sourceforge mailing 
lists are so much more user friendly.

I am trying to send the report generated by the second script for all 
the relevant files pertaining to one note ie L for main and 3 releases, 
R for main and 3 releases and another set of the combined samples.

I guess we just have to wait until the moderators release my post which 
I had to send a number of times without success.

Regards

Mark


On 14/12/2016 15:56, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-14 13:58, Dr. Mark Bugeja MD wrote:
>> There is no instruction to make a copy of sox,exe and to rename it as
>> soxi.exe
>>
>> :-P
> There is in the download zip for sox that I have, in file:
> README.win32.txt
>



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

[-- Attachment #1.2: Type: text/html, Size: 2388 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[fmiser]

> Dr. wrote:

> my replies are no getting through.  The amount of text is making
> the files too big.

> I am trying to send the report generated by the second script
> for all the relevant files pertaining to one note ie L for main
> and 3 releases, R for main and 3 releases and another set of the
> combined samples.

I see a long one (with HTML) that has a number of bassoon L and R
as well as a few stereo.  It has Jeremy's post at the bottom, so I
suspect it all got through.

> This list is so frustrating. Other sourceforge mailing lists are
> so much more user friendly.

I'm sorry you think so.  I happen to find this one _much_ more
user friendly.  Email lists like this have been around for 30
years or so and are pretty refined.  Especially for those of us
who don't have a no-cost high bandwidth internet connection there
is nothing that does better.
It's different than web forums, but if you compose in plain text
(not HTML) and don't use attachment, it largely just works.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 3137 bytes --]

c:\>"C:\Program Files (x86)\sox-14-4-2\soxi.exe" 
"E:\Recit-Organ\Basson16L\Main\036-C.wav"

Input File     : 'E:\Recit-Organ\Basson16L\Main\036-C.wav'
Channels       : 2
Sample Rate    : 48000
Precision      : 24-bit
Duration       : 00:00:08.75 = 419980 samples ~ 656.219 CDDA sectors
File Size      : 2.52M
Bit Rate       : 2.30M
Sample Encoding: 24-bit Signed Integer PCM


c:\>"C:\Program Files (x86)\sox-14-4-2\soxi.exe" 
"E:\Recit-Organ\Basson16R\Main\036-C.wav"

Input File     : 'E:\Recit-Organ\Basson16R\Main\036-C.wav'
Channels       : 2
Sample Rate    : 48000
Precision      : 24-bit
Duration       : 00:00:08.75 = 419980 samples ~ 656.219 CDDA sectors
File Size      : 2.52M
Bit Rate       : 2.30M
Sample Encoding: 24-bit Signed Integer PCM


c:\>"C:\Program Files (x86)\sox-14-4-2\soxi.exe" "D:\St Mary's 
Abbey\Recit\Basson16\036-C.wav"

Input File     : 'D:\St Mary's Abbey\Recit\Basson16\036-C.wav'
Channels       : 2
Sample Rate    : 48000
Precision      : 24-bit
Duration       : 00:00:08.75 = 419980 samples ~ 656.219 CDDA sectors
File Size      : 2.52M
Bit Rate       : 2.30M
Sample Encoding: 24-bit Signed Integer PCM



On 14/12/2016 00:48, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-13 18:39, Dr. Mark Bugeja MD wrote:
>> I have tested the wav samples. They won't load in the software
>> GrandOrgue and give a PCM format error. Could this have something to
>> do with the merging process we have just done?
> Who knows?
>
> I had the impression you earlier tested a merge and decided the
> resulting file
> was ok (either it sounded ok, or it looked ok in some other program)?
> Was that
> so?
>
> If so, do the files merged by the script also sound ok to you, or look
> ok, doing
> whatever it was that you did before to check a file?
>
>
>
> Take one example (ie a left file, a right file and file that was merged
> from them),
> and for each of those files issue in a command window this command
> (though use the
> paths that make sense on your computer):
>
>    "C:\path\to\sox\soxi.exe" "C:\path\to\audio-files\some.wav"
>
> Note that this runs "soxi.exe" not "sox.exe".  Make sure that you have a
> soxi.exe
> (in the same place as you have sox.exe).
>
> Paste the command you issued and whatever the result was, for each file,
> in your
> next reply.
>
> Also issue, for each file, this command:
>
>    "C:\path\to\sox\sox.exe" "C:\path\to\audio-files\some.wav" -n stat
> stats
>
> and paste those commands and results into your reply too.  Note that
> this command
> called 'sox' not 'soxi', and the 'stat stats' part runs two separate
> effects which
> will list details about the audio data in the file concerned.
>
>
> So, that's three separate commands to be issued, against three separate
> files.
> Hopefully something in the details the three commands list will give
> someone here a
> clue as to what might be wrong.
>
>
> Do you remember earlier in the discussion someone pointed out that,
> really, scripts
> should check things?  The script you've been running checks nothing.
>



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

[-- Attachment #1.2: Type: text/html, Size: 4790 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-14 14:21, Dr. Mark Bugeja MD wrote:
> c:\>"C:\Program Files (x86)\sox-14-4-2\soxi.exe"
> "E:\Recit-Organ\Basson16L\Main\036-C.wav"
> 
> Input File     : 'E:\Recit-Organ\Basson16L\Main\036-C.wav'
> Channels       : 2
> Sample Rate    : 48000
> Precision      : 24-bit
> Duration       : 00:00:08.75 = 419980 samples ~ 656.219 CDDA sectors
> File Size      : 2.52M
> Bit Rate       : 2.30M
> Sample Encoding: 24-bit Signed Integer PCM

etc...

That's good - but assuming that the  'D:\St Mary's 
Abbey\Recit\Basson16\036-C.wav'  file
is the one without the error, you omitted the stereo file that did have 
the error.

And you need to do the: sox  ...  -n stat stats     commands as well.

-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Dr. Mark Bugeja MD]

[-- Attachment #1.1: Type: text/plain, Size: 11300 bytes --]

I have run the other script this time for all the related files ie the L 
& R for main and 3 release files and the merged main and 3 releases.

Midline amplitude:     0.020637
Mean    norm:          0.003155
Mean    amplitude:     0.000002
RMS     amplitude:     0.011313
Maximum delta:         0.295773
Minimum delta:         0.000000
Mean    delta:         0.006311
RMS     delta:         0.015999
Rough   frequency:        10803
Volume adjustment:        3.381
              Overall     Left      Right
DC offset   0.000004  0.000000  0.000004
Min level  -0.254498 -0.000000 -0.254498
Max level   0.295773  0.000000  0.295773
Pk lev dB     -10.58   -138.47    -10.58
RMS lev dB    -38.93   -141.48    -35.92
RMS Pk dB     -27.93   -141.26    -27.93
RMS Tr dB    -141.69   -141.69    -89.82
Crest factor       -      1.41     18.49
Flat factor     9.48      9.48      0.00
Pk count       64.3k      129k         2
Bit-depth      23/24      1/24     23/24
Num samples     257k
Length s       5.357
Scale max   1.000000
Window s       0.050

c:\>"C:\Program Files (x86)\sox-14-4-2\sox.exe" 
"E:\Recit-Organ\Basson16L\rel00600\036-C.wav" -n stat stats
Samples read:            532806
Length (seconds):      5.550063
Scaled by:         2147483647.0
Maximum amplitude:     0.204444
Minimum amplitude:    -0.245520
Midline amplitude:    -0.020538
Mean    norm:          0.004573
Mean    amplitude:     0.000001
RMS     amplitude:     0.015371
Maximum delta:         0.245520
Minimum delta:         0.000000
Mean    delta:         0.009145
RMS     delta:         0.021737
Rough   frequency:        10803
Volume adjustment:        4.073
              Overall     Left      Right
DC offset   0.000002  0.000002  0.000000
Min level  -0.245520 -0.245520 -0.000000
Max level   0.204444  0.204444  0.000000
Pk lev dB     -12.20    -12.20   -138.47
RMS lev dB    -36.27    -33.26   -141.49
RMS Pk dB     -23.04    -23.04   -141.27
RMS Tr dB    -141.70    -84.88   -141.70
Crest factor       -     11.29      1.41
Flat factor     9.53      0.00      9.53
Pk count       66.5k         2      133k
Bit-depth      22/24     22/24      1/24
Num samples     266k
Length s       5.550
Scale max   1.000000
Window s       0.050

c:\>"C:\Program Files (x86)\sox-14-4-2\sox.exe" 
"E:\Recit-Organ\Basson16R\rel00600\036-C.wav" -n stat stats
Samples read:            532806
Length (seconds):      5.550063
Scaled by:         2147483647.0
Maximum amplitude:     0.301633
Minimum amplitude:    -0.330314
Midline amplitude:    -0.014341
Mean    norm:          0.004733
Mean    amplitude:     0.000001
RMS     amplitude:     0.015898
Maximum delta:         0.330314
Minimum delta:         0.000000
Mean    delta:         0.009466
RMS     delta:         0.022483
Rough   frequency:        10803
Volume adjustment:        3.027
              Overall     Left      Right
DC offset   0.000002  0.000000  0.000002
Min level  -0.330314 -0.000000 -0.330314
Max level   0.301633  0.000000  0.301633
Pk lev dB      -9.62   -138.47     -9.62
RMS lev dB    -35.97   -141.48    -32.96
RMS Pk dB     -23.59   -141.24    -23.59
RMS Tr dB    -141.70   -141.70    -91.28
Crest factor       -      1.41     14.69
Flat factor     9.55      9.55      0.00
Pk count       66.6k      133k         2
Bit-depth      23/24      1/24     23/24
Num samples     266k
Length s       5.550
Scale max   1.000000
Window s       0.050

c:\>"C:\Program Files (x86)\sox-14-4-2\sox.exe" 
"E:\Recit-Organ\Basson16L\rel99999\036-C.wav" -n stat stats
Samples read:            601084
Length (seconds):      6.261292
Scaled by:         2147483647.0
Maximum amplitude:     0.320890
Minimum amplitude:    -0.359950
Midline amplitude:    -0.019530
Mean    norm:          0.006878
Mean    amplitude:     0.000002
RMS     amplitude:     0.023389
Maximum delta:         0.359950
Minimum delta:         0.000000
Mean    delta:         0.013755
RMS     delta:         0.033077
Rough   frequency:        10803
Volume adjustment:        2.778
              Overall     Left      Right
DC offset   0.000004  0.000004  0.000000
Min level  -0.359950 -0.359950 -0.000000
Max level   0.320890  0.320890  0.000000
Pk lev dB      -8.88     -8.88   -138.47
RMS lev dB    -32.62    -29.61   -141.48
RMS Pk dB     -19.77    -19.77   -141.23
RMS Tr dB    -141.68    -80.80   -141.68
Crest factor       -     10.88      1.41
Flat factor     9.56      0.00      9.56
Pk count       75.2k         2      150k
Bit-depth      23/24     23/24      1/24
Num samples     301k
Length s       6.261
Scale max   1.000000
Window s       0.050

c:\>"C:\Program Files (x86)\sox-14-4-2\sox.exe" 
"E:\Recit-Organ\Basson16R\rel99999\036-C.wav" -n stat stats
Samples read:            601084
Length (seconds):      6.261292
Scaled by:         2147483647.0
Maximum amplitude:     0.438307
Minimum amplitude:    -0.486701
Midline amplitude:    -0.024197
Mean    norm:          0.008901
Mean    amplitude:     0.000003
RMS     amplitude:     0.030132
Maximum delta:         0.486701
Minimum delta:         0.000000
Mean    delta:         0.017802
RMS     delta:         0.042613
Rough   frequency:        10803
Volume adjustment:        2.055
              Overall     Left      Right
DC offset   0.000007  0.000000  0.000007
Min level  -0.486701 -0.000000 -0.486701
Max level   0.438307  0.000000  0.438307
Pk lev dB      -6.25   -138.47     -6.25
RMS lev dB    -30.42   -141.49    -27.41
RMS Pk dB     -18.41   -141.31    -18.41
RMS Tr dB    -141.71   -141.71    -87.29
Crest factor       -      1.42     11.42
Flat factor     9.51      9.51      0.00
Pk count       75.0k      150k         2
Bit-depth      23/24      1/24     23/24
Num samples     301k
Length s       6.261
Scale max   1.000000
Window s       0.050

c:\>"C:\Program Files (x86)\sox-14-4-2\sox.exe" "D:\St Mary's 
Abbey\Recit\Basson16\036-C.wav" -n stat stats
Samples read:            839960
Length (seconds):      8.749583
Scaled by:         2147483647.0
Maximum amplitude:     0.658200
Minimum amplitude:    -0.761482
Midline amplitude:    -0.051641
Mean    norm:          0.145129
Mean    amplitude:    -0.000000
RMS     amplitude:     0.183539
Maximum delta:         0.865200
Minimum delta:         0.000000
Mean    delta:         0.171522
RMS     delta:         0.214170
Rough   frequency:         8914
Volume adjustment:        1.313
              Overall     Left      Right
DC offset  -0.000004 -0.000004  0.000004
Min level  -0.761482 -0.579805 -0.761482
Max level   0.658200  0.658200  0.620411
Pk lev dB      -2.37     -3.63     -2.37
RMS lev dB    -14.73    -15.31    -14.21
RMS Pk dB     -12.63    -12.88    -12.63
RMS Tr dB     -19.82    -19.82    -18.53
Crest factor       -      3.84      3.91
Flat factor     0.00      0.00      0.00
Pk count           2         2         2
Bit-depth      24/24     24/24     24/24
Num samples     420k
Length s       8.750
Scale max   1.000000
Window s       0.050

c:\>"C:\Program Files (x86)\sox-14-4-2\sox.exe" "D:\St Mary's 
Abbey\Recit\Basson16\REL00150\036-C.wav" -n stat stats
Samples read:            514288
Length (seconds):      5.357167
Scaled by:         2147483647.0
Maximum amplitude:     0.298661
Minimum amplitude:    -0.274763
Midline amplitude:     0.011949
Mean    norm:          0.005982
Mean    amplitude:     0.000009
RMS     amplitude:     0.015084
Maximum delta:         0.405352
Minimum delta:         0.000000
Mean    delta:         0.008421
RMS     delta:         0.020733
Rough   frequency:        10499
Volume adjustment:        3.348
              Overall     Left      Right
DC offset   0.000014  0.000014  0.000004
Min level  -0.274763 -0.274763 -0.254498
Max level   0.298661  0.298661  0.295773
Pk lev dB     -10.50    -10.50    -10.58
RMS lev dB    -36.43    -37.01    -35.92
RMS Pk dB     -27.93    -27.94    -27.93
RMS Tr dB     -91.34    -91.34    -89.82
Crest factor       -     21.17     18.49
Flat factor     0.00      0.00      0.00
Pk count           2         2         2
Bit-depth      23/24     23/24     23/24
Num samples     257k
Length s       5.357
Scale max   1.000000
Window s       0.050

c:\>"C:\Program Files (x86)\sox-14-4-2\sox.exe" "D:\St Mary's 
Abbey\Recit\Basson16\REL00600\036-C.wav" -n stat stats
Samples read:            532806
Length (seconds):      5.550063
Scaled by:         2147483647.0
Maximum amplitude:     0.301633
Minimum amplitude:    -0.330314
Midline amplitude:    -0.014341
Mean    norm:          0.009306
Mean    amplitude:     0.000002
RMS     amplitude:     0.022114
Maximum delta:         0.386482
Minimum delta:         0.000000
Mean    delta:         0.013272
RMS     delta:         0.030727
Rough   frequency:        10615
Volume adjustment:        3.027
              Overall     Left      Right
DC offset   0.000002  0.000002  0.000002
Min level  -0.330314 -0.245520 -0.330314
Max level   0.301633  0.204444  0.301633
Pk lev dB      -9.62    -12.20     -9.62
RMS lev dB    -33.11    -33.26    -32.96
RMS Pk dB     -23.04    -23.04    -23.59
RMS Tr dB     -91.28    -84.88    -91.28
Crest factor       -     11.29     14.69
Flat factor     0.00      0.00      0.00
Pk count           2         2         2
Bit-depth      23/24     22/24     23/24
Num samples     266k
Length s       5.550
Scale max   1.000000
Window s       0.050

c:\>"C:\Program Files (x86)\sox-14-4-2\sox.exe" "D:\St Mary's 
Abbey\Recit\Basson16\REL99999\036-C.wav" -n stat stats
Samples read:            601084
Length (seconds):      6.261292
Scaled by:         2147483647.0
Maximum amplitude:     0.438307
Minimum amplitude:    -0.486701
Midline amplitude:    -0.024197
Mean    norm:          0.015779
Mean    amplitude:     0.000005
RMS     amplitude:     0.038144
Maximum delta:         0.657312
Minimum delta:         0.000000
Mean    delta:         0.021906
RMS     delta:         0.051787
Rough   frequency:        10371
Volume adjustment:        2.055
              Overall     Left      Right
DC offset   0.000007  0.000004  0.000007
Min level  -0.486701 -0.359950 -0.486701
Max level   0.438307  0.320890  0.438307
Pk lev dB      -6.25     -8.88     -6.25
RMS lev dB    -28.37    -29.61    -27.41
RMS Pk dB     -18.41    -19.77    -18.41
RMS Tr dB     -87.29    -80.80    -87.29
Crest factor       -     10.88     11.42
Flat factor     0.00      0.00      0.00
Pk count           2         2         2
Bit-depth      23/24     23/24     23/24
Num samples     301k
Length s       6.261
Scale max   1.000000
Window s       0.050

c:\>


On 14/12/2016 15:53, Jeremy Nicoll - ml sox users wrote:
> On 2016-12-14 14:21, Dr. Mark Bugeja MD wrote:
>> c:\>"C:\Program Files (x86)\sox-14-4-2\soxi.exe"
>> "E:\Recit-Organ\Basson16L\Main\036-C.wav"
>>
>> Input File     : 'E:\Recit-Organ\Basson16L\Main\036-C.wav'
>> Channels       : 2
>> Sample Rate    : 48000
>> Precision      : 24-bit
>> Duration       : 00:00:08.75 = 419980 samples ~ 656.219 CDDA sectors
>> File Size      : 2.52M
>> Bit Rate       : 2.30M
>> Sample Encoding: 24-bit Signed Integer PCM
> etc...
>
> That's good - but assuming that the  'D:\St Mary's
> Abbey\Recit\Basson16\036-C.wav'  file
> is the one without the error, you omitted the stereo file that did have
> the error.
>
> And you need to do the: sox  ...  -n stat stats     commands as well.
>



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

[-- Attachment #1.2: Type: text/html, Size: 16151 bytes --]

[-- Attachment #2: Type: text/plain, Size: 203 bytes --]

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

[-- Attachment #3: Type: text/plain, Size: 158 bytes --]

_______________________________________________
Sox-users mailing list
Sox-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sox-users

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-14 15:27, Dr. Mark Bugeja MD wrote:
> I have run the other script this time for all the related files ie the
> L & R for main and 3 release files and the merged main and 3 releases.
> 
> Midline amplitude:     0.020637
> Mean    norm:          0.003155
> Mean    amplitude:     0.000002
...
...


Which file were these first listed results for?


Which of your files are the ones that show the PCM format error, and 
which seem
to be ok?


Also, you said you'd run the script (it's not a script, it's just a 
single command
- a script is something with a series of commands in it) for "the L & R 
for main
and 3 release files and the merged main and 3 releases." which I thought 
would be
main (2 files, L&R), 3 releases (6 files, ie 3 sets of L&R), merged main 
(1 stereo
file), merged releases (3 stereo files) in other words 12 commands and 
results...
but you've only included 9 results.


And there should be 12 sets of soxi commands and results.


Do you get any other error messages?

Will any, or all, of these files load into other software, eg - if you 
have it -
Audacity?


-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-14 14:21, Dr. Mark Bugeja MD wrote:
> c:\>"C:\Program Files (x86)\sox-14-4-2\soxi.exe"
> "E:\Recit-Organ\Basson16L\Main\036-C.wav"
> 
> Input File     : 'E:\Recit-Organ\Basson16L\Main\036-C.wav'
> Channels       : 2
...

There should be another 9 soxi commands and results...


-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

Re: Fwd: Re: Fwd: Re: merging mono files

[Jeremy Nicoll - ml sox users]

On 2016-12-13 18:39, Dr. Mark Bugeja MD wrote:
> I have tested the wav samples. They won't load in the software
> GrandOrgue and give a PCM format error.

Could you ask on the GO discussion forum whether anyone else has had the 
same
error message(s) as you've had?  There's no point in me asking there 
because
I nothing at all about GO.

Also, I'm puzzled what a "PCM format error" might be; as far as I 
understand
it, PCM audio data is uncompressed and has (I thought) no or little that 
one
might call "a format" in the files.

-- 
Jeremy Nicoll - my opinions are my own

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot