gwc-general — Gnome Wave Cleaner discussion list

Re: [Gwc-general] Encoding to MP3 problem, byte swapping occurs

[Alister H. <ali...@gm...>]

Hi John,

I've found the current version of gwc (I'm not sure about old ones) 
freezes if I try to "Encode Selection As..." mp3 or ogg, but "Simple 
encode selection as mp3" works fine.
FWIW I currently have lame 3.99.5

John Cirillo wrote, On 24/09/14 03:47:
> I just installed gwc on my work computer and when I go to encode to 
> mp3, I see a message in the command line that:
> Assuming raw pcm input file : Forcing byte-swapping
> As a result the mp3 is garbage, just a loud hiss.
> I remember that this started happening long ago at home, and has 
> persisted ever since then, persisting through complete reinstalls.  It 
> is not dependent on the version of gwc.
> I am currently at 0.21.18 at work because 0.21.19 freezes when I try 
> to save anything.
> At home I think I'm using 0.21.05.
> I seem to remember having reported this problem before, and  so far 
> the only solution has been to uninstall lame and force an install of 
> lame 3.97 which I kept from my old Squeeze install (or before).
> The newer lames work fine when encoding a .wav from command line but 
> from gwc this byte-swapping happens.
> Is there something I can do, maybe something I can set in gwc?
> I can't believe I'm the only one who has encountered this. Happens 
> consistently on three computers (work, home, and laptop).  I think it 
> started happening on or after Squeeze. I've gone through Wheezy and 
> now at Jessie with the same problem.  Installing lame 3.97 seems the 
> only solution.  I don't understand.
>
> Thanks,
> John Cirillo

[Gwc-general] Encoding to MP3 problem, byte swapping occurs

[John C. <jo...@in...>]

I just installed gwc on my work computer and when I go to encode to mp3, 
I see a message in the command line that:
Assuming raw pcm input file : Forcing byte-swapping
As a result the mp3 is garbage, just a loud hiss.
I remember that this started happening long ago at home, and has 
persisted ever since then, persisting through complete reinstalls.  It 
is not dependent on the version of gwc.
I am currently at 0.21.18 at work because 0.21.19 freezes when I try to 
save anything.
At home I think I'm using 0.21.05.
I seem to remember having reported this problem before, and  so far the 
only solution has been to uninstall lame and force an install of lame 
3.97 which I kept from my old Squeeze install (or before).
The newer lames work fine when encoding a .wav from command line but 
from gwc this byte-swapping happens.
Is there something I can do, maybe something I can set in gwc?
I can't believe I'm the only one who has encountered this. Happens 
consistently on three computers (work, home, and laptop). I think it 
started happening on or after Squeeze.  I've gone through Wheezy and now 
at Jessie with the same problem. Installing lame 3.97 seems the only 
solution.  I don't understand.

Thanks,
John Cirillo

[Gwc-general] Porting GWC from gnome libs to plain gtk

[Alister H. <ali...@gm...>]

Hi, and firstly, thanks Jeff for the great software.
Dependencies on the gnome libs always annoyed me, and now they are 
thoroughly obsolete.
GWC is important to me, so I thought I'd try porting it to use plain gtk 
libs.
I haven't yet done the main change: migrating from gnomeuiinfo 
(gnome-app-helper) to GtkAction and GtkUIManager (see 
https://developer.gnome.org/gtk2/stable/migrating-gnomeuiinfo.html), but 
I think I've done all the other bits and pieces, which has also tidied 
up various bugs, some of which I found quite annoying.
It is here for anyone who wants to check it out: 
https://github.com/AlisterH/gwc

Regards,
Alister

[Gwc-general] gwc 0.21-19 released

[jeff w. <we...@ya...>]

>From the Changelog:
0.21-19
Feb 2,2013
BUGFIX: warning on opening audio device incorrectly displayed pulse audio message when neither alsa or pulse audio was being used
BUGFIX: Encoding to ogg or mp3 has always been broken, can only encode to once during GWC session.  Fixed by using named pipe
NEW: A simple front end for encoding to MP3s.  Only a -V xx encoding option,
but can have default artist and album tags now, and enter trackname when
encoding the selection.  Kind of klunky user interface, but it works.

Enjoy!

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[jeff w. <we...@ya...>]

Yay!  Looks like there is still a bug in the warning message printed out making you think gwc is using the pulsaudio device, when it really is using alsa from the configure.  I'll think about that a little bit too, but it's an annoyance, not a showstopper for the moment.

Thanks for being a tester!
Happy denoising!
Jeff



________________________________
 From: Chris Green <cl...@is...>
To: "gwc...@li..." <gwc...@li...> 
Sent: Saturday, February 2, 2013 8:06 AM
Subject: Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10
 
On Sat, Feb 02, 2013 at 06:31:42AM -0800, jeff welty wrote:
>    When you run the configure script, by default gwc will use the ALSA sound
>    driver.
>    So find the pulse audio development libraries (not sure what they are
>    called on ubuntu), then try:
>    "configure --enable-pa"

Ah!  :-)

>    (configure should print a little message about using pulse audio, if it
>    doesn't then you don't have the correct pulse audio development libs
>    installed)

Exactly, I had to install libpulse-dev.  It would be good if configure
output an error if you ask for --enable-pa and the library/headers
aren't there.


>    Once that succeeds, do:
>    "rm *.o"
>    "make"
> 
Yes, I have a fully working 0.21-18 now and I'm not getting any
 errors.
When run from the command line it reports:-

    Current stack limit: 8388608 bytes
    libsndfile Version: libsndfile-1.0.25 1 0 25
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    ...
    ...

Which looks quite encouraging.

Thanks for all the help and hard work!

-- 
Chris
 Green

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gwc-general mailing list
Gwc...@li...
https://lists.sourceforge.net/lists/listinfo/gwc-general

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[Chris G. <cl...@is...>]

On Sat, Feb 02, 2013 at 06:31:42AM -0800, jeff welty wrote:
>    When you run the configure script, by default gwc will use the ALSA sound
>    driver.
>    So find the pulse audio development libraries (not sure what they are
>    called on ubuntu), then try:
>    "configure --enable-pa"

Ah!  :-)

>    (configure should print a little message about using pulse audio, if it
>    doesn't then you don't have the correct pulse audio development libs
>    installed)

Exactly, I had to install libpulse-dev.  It would be good if configure
output an error if you ask for --enable-pa and the library/headers
aren't there.


>    Once that succeeds, do:
>    "rm *.o"
>    "make"
> 
Yes, I have a fully working 0.21-18 now and I'm not getting any errors.
When run from the command line it reports:-

    Current stack limit: 8388608 bytes
    libsndfile Version: libsndfile-1.0.25 1 0 25
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    Closing the Pulse audio device
    Open the Pulse audio device
    ...
    ...

Which looks quite encouraging.

Thanks for all the help and hard work!

-- 
Chris Green

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[jeff w. <we...@ya...>]

When you run the configure script, by default gwc will use the ALSA sound driver.

So find the pulse audio development libraries (not sure what they are called on ubuntu), then try:


"configure --enable-pa"

(configure should print a little message about using pulse audio, if it doesn't then you don't have the correct pulse audio development libs installed)

Once that succeeds, do:

"rm *.o"
"make"



________________________________
 From: Chris Green <cl...@is...>
To: "gwc...@li..." <gwc...@li...> 
Sent: Saturday, February 2, 2013 4:26 AM
Subject: Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10
 
On Fri, Feb 01, 2013 at 07:04:47PM -0800, jeff welty wrote:
>    I just uploaded 0.21-18 to sourceforge.  I found a bug in the way gwc was
>    connecting to pulse audio and checking for the failure to connect.  This
>    explains the mysterious and erratic messages gwc was generating about not
>    opening the pulse audio every other time, but only under certain
>    circumstances.
>    Give it a try when you can.

Thanks!

It took a while to get all the required dependencies as I needed lots of
xxxx-dev packages where I only had the basic libraries.  In particular
libgnomeui-dev pulled in dozens of further dependencies.

However once configure had done its worst it built OK and.... oh dear,
now it just fails every time I try playback, with the message:-

   Failed to open Pulse audio output device, recommend internet search
   about pulse audion configuration for your OS

Wierdly the default version 0.21-17 is now working faultlessly however
often I start and stop playback!

-- 
Chris Green

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
_______________________________________________
Gwc-general mailing list
Gwc...@li...
https://lists.sourceforge.net/lists/listinfo/gwc-general

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[Chris G. <cl...@is...>]

On Fri, Feb 01, 2013 at 07:04:47PM -0800, jeff welty wrote:
>    I just uploaded 0.21-18 to sourceforge.  I found a bug in the way gwc was
>    connecting to pulse audio and checking for the failure to connect.  This
>    explains the mysterious and erratic messages gwc was generating about not
>    opening the pulse audio every other time, but only under certain
>    circumstances.
>    Give it a try when you can.

Thanks!

It took a while to get all the required dependencies as I needed lots of
xxxx-dev packages where I only had the basic libraries.  In particular
libgnomeui-dev pulled in dozens of further dependencies.

However once configure had done its worst it built OK and.... oh dear,
now it just fails every time I try playback, with the message:-

   Failed to open Pulse audio output device, recommend internet search
   about pulse audion configuration for your OS

Wierdly the default version 0.21-17 is now working faultlessly however
often I start and stop playback!

-- 
Chris Green

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[jeff w. <we...@ya...>]

I just uploaded 0.21-18 to sourceforge.  I found a bug in the way gwc was connecting to pulse audio and checking for the failure to connect.  This explains the mysterious and erratic messages gwc was generating about not opening the pulse audio every other time, but only under certain circumstances.

Give it a try when you can.

Cheers,
Jeff

________________________________
 From: Chris Green <cl...@is...>
To: "gwc...@li..." <gwc...@li...> 
Sent: Monday, January 28, 2013 1:33 AM
Subject: Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10
 
On Sun, Jan 27, 2013 at 05:30:00PM -0800, jeff welty wrote:
>    Hi Chris,
>    I think John Cirillo was on the right track, sort of.  But I think also
>    the way GWC connect to pulse audio might have a bug.  I hadn't compiled
>    and run gwc for a while, and I just did on my Fedora Core 17 machine,
>    running the gnome window manager.
>    With nothing else running, I have no problems with playback.
>    But, if I crank up a streaming application (like grooveshark), in firefox,
>    I get the same problem you have described, play only works every other
>    time.

Thanks for taking a look.  It's not quite as consistently 'every other
time' as I originally thought and *seems* to act rather differently if I
use the space bar to start and stop rather than the icons.  It still
happens using the space bar though.

I think (among other things) I have Music Player Daemon running on the
same system so there's at least one other pulseaudio client, I might try
stopping it (MPD) to see if that fixes it.

>    If I get a chance, I'll poke around at the pulse audio code for GWC.  When
>    I imlemented it pulse audio was still pretty young so I didn't work too
>    hard at it.  Maybe there is an error return that the code can sense and
>    attempt a reconnect to the audio driver automatically instead of just
>    failing and popping up the error dialog.
>    Thanks for trying GWC and especially thanks for reporting the problem!

If there's anything I can do to help investigate/debug then please ask.

-- 
Chris Green

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Gwc-general mailing list
Gwc...@li...
https://lists.sourceforge.net/lists/listinfo/gwc-general

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[Chris G. <cl...@is...>]

On Sun, Jan 27, 2013 at 05:30:00PM -0800, jeff welty wrote:
>    Hi Chris,
>    I think John Cirillo was on the right track, sort of.  But I think also
>    the way GWC connect to pulse audio might have a bug.  I hadn't compiled
>    and run gwc for a while, and I just did on my Fedora Core 17 machine,
>    running the gnome window manager.
>    With nothing else running, I have no problems with playback.
>    But, if I crank up a streaming application (like grooveshark), in firefox,
>    I get the same problem you have described, play only works every other
>    time.

Thanks for taking a look.  It's not quite as consistently 'every other
time' as I originally thought and *seems* to act rather differently if I
use the space bar to start and stop rather than the icons.  It still
happens using the space bar though.

I think (among other things) I have Music Player Daemon running on the
same system so there's at least one other pulseaudio client, I might try
stopping it (MPD) to see if that fixes it.

>    If I get a chance, I'll poke around at the pulse audio code for GWC.  When
>    I imlemented it pulse audio was still pretty young so I didn't work too
>    hard at it.  Maybe there is an error return that the code can sense and
>    attempt a reconnect to the audio driver automatically instead of just
>    failing and popping up the error dialog.
>    Thanks for trying GWC and especially thanks for reporting the problem!

If there's anything I can do to help investigate/debug then please ask.

-- 
Chris Green

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[jeff w. <we...@ya...>]

Hi Chris,

I think John Cirillo was on the right track, sort of.  But I think also the way GWC connect to pulse audio might have a bug.  I hadn't compiled and run gwc for a while, and I just did on my Fedora Core 17 machine, running the gnome window manager.

With nothing else running, I have no problems with playback.

But, if I crank up a streaming application (like grooveshark), in firefox, I get the same problem you have described, play only works every other time.

If I get a chance, I'll poke around at the pulse audio code for GWC.  When I imlemented it pulse audio was still pretty young so I didn't work too hard at it.  Maybe there is an error return that the code can sense and attempt a reconnect to the audio driver automatically instead of just failing and popping up the error dialog.

Thanks for trying GWC and especially thanks for reporting the problem!

Cheers,
Jeff


________________________________
 From: Chris Green <cl...@is...>
To: gwc...@li... 
Sent: Friday, January 25, 2013 7:09 AM
Subject: Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10
 
On Thu, Jan 24, 2013 at 01:54:44PM -0500, John Cirillo wrote:
> On 1/24/2013 12:07 PM, Chris Green wrote:
> > On Thu, Jan 24, 2013 at 11:04:58AM -0500, John Cirillo wrote:
> >> I seem to remember this happened a few years ago and in my
> >> case was caused by the KDE
> >> notification timeout defaulting to something too long, like
> >> 5 seconds or so.
> >> Because of that, the audio system really was temporarily
> >> busy, but for no useful reason.
> >> After I changed the KDE event notification timeout to 1
> >> second, all was well from then on.
> >> Something to check.  Not sure if other window managers have
> >> something similar.
> >>
> > I don't run KDE but I do have a KDE application (k3b) so it *might* be
> > the KDE event notification.  Do you know where I might be able to see
> > and/or change the KDE event notification timeout without the KDE GUI
> > running?
> >
> I don't think that the KDE sound system nor notification 
> system is running if you aren't using KDE.  Doesn't matter 
> if you have some KDE apps installed.  But as to where KDE 
> sets this, I couldn't find it.  I tried changing my timeout 
> from within the GUI and couldn't find any altered config 
> file either in the .kde directory under my user, or in 
> /usr/share/kde4.  Sorry.
> 
OK, thanks for looking anyway.

-- 
Chris Green

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Gwc-general mailing list
Gwc...@li...
https://lists.sourceforge.net/lists/listinfo/gwc-general

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[Chris G. <cl...@is...>]

On Thu, Jan 24, 2013 at 01:54:44PM -0500, John Cirillo wrote:
> On 1/24/2013 12:07 PM, Chris Green wrote:
> > On Thu, Jan 24, 2013 at 11:04:58AM -0500, John Cirillo wrote:
> >> I seem to remember this happened a few years ago and in my
> >> case was caused by the KDE
> >> notification timeout defaulting to something too long, like
> >> 5 seconds or so.
> >> Because of that, the audio system really was temporarily
> >> busy, but for no useful reason.
> >> After I changed the KDE event notification timeout to 1
> >> second, all was well from then on.
> >> Something to check.  Not sure if other window managers have
> >> something similar.
> >>
> > I don't run KDE but I do have a KDE application (k3b) so it *might* be
> > the KDE event notification.  Do you know where I might be able to see
> > and/or change the KDE event notification timeout without the KDE GUI
> > running?
> >
> I don't think that the KDE sound system nor notification 
> system is running if you aren't using KDE.  Doesn't matter 
> if you have some KDE apps installed.  But as to where KDE 
> sets this, I couldn't find it.  I tried changing my timeout 
> from within the GUI and couldn't find any altered config 
> file either in the .kde directory under my user, or in 
> /usr/share/kde4.  Sorry.
> 
OK, thanks for looking anyway.

-- 
Chris Green

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[John C. <ci...@pu...>]

On 1/24/2013 12:07 PM, Chris Green wrote:
> On Thu, Jan 24, 2013 at 11:04:58AM -0500, John Cirillo wrote:
>> I seem to remember this happened a few years ago and in my
>> case was caused by the KDE
>> notification timeout defaulting to something too long, like
>> 5 seconds or so.
>> Because of that, the audio system really was temporarily
>> busy, but for no useful reason.
>> After I changed the KDE event notification timeout to 1
>> second, all was well from then on.
>> Something to check.  Not sure if other window managers have
>> something similar.
>>
> I don't run KDE but I do have a KDE application (k3b) so it *might* be
> the KDE event notification.  Do you know where I might be able to see
> and/or change the KDE event notification timeout without the KDE GUI
> running?
>
I don't think that the KDE sound system nor notification 
system is running if you aren't using KDE.  Doesn't matter 
if you have some KDE apps installed.  But as to where KDE 
sets this, I couldn't find it.  I tried changing my timeout 
from within the GUI and couldn't find any altered config 
file either in the .kde directory under my user, or in 
/usr/share/kde4.  Sorry.

John

>> On 1/24/2013 8:59 AM, Chris Green wrote:
>>> I have just installed Gnome Wave Cleaner version 0.21-17 on my xubuntu
>>> 12.10 system, it works very well for me but there is one odd little
>>> bug I would like to clear up.
>>>
>>> When I use the icons to start and stop playing a section of a recording
>>> they work one time and then fail with two pop-up errors:-
>>>
>>>       Warning
>>>       audio_device_open: pa_simple_new
>>>
>>> then
>>>
>>>       Warning
>>>       Failed to open output device default:, check settings->miscellaneous
>>>       for device information
>>>
>>>
>>> If I click OK on both of these then the next time I click the Play icon
>>> it plays OK.
>>>
>>> I have tried changing the device in settings->miscellaneous from
>>> /dev/dsp to default: but it seems to have made no difference.
>>>
>>> While I'm about it what's the correct device to use when using gwc with
>>> pulseaudio, I couldn't find any information on this.
>>>
>

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[Chris G. <cl...@is...>]

On Thu, Jan 24, 2013 at 11:04:58AM -0500, John Cirillo wrote:
> I seem to remember this happened a few years ago and in my 
> case was caused by the KDE
> notification timeout defaulting to something too long, like 
> 5 seconds or so.
> Because of that, the audio system really was temporarily 
> busy, but for no useful reason.
> After I changed the KDE event notification timeout to 1 
> second, all was well from then on.
> Something to check.  Not sure if other window managers have 
> something similar.
> 
I don't run KDE but I do have a KDE application (k3b) so it *might* be
the KDE event notification.  Do you know where I might be able to see
and/or change the KDE event notification timeout without the KDE GUI
running?

> On 1/24/2013 8:59 AM, Chris Green wrote:
> > I have just installed Gnome Wave Cleaner version 0.21-17 on my xubuntu
> > 12.10 system, it works very well for me but there is one odd little
> > bug I would like to clear up.
> >
> > When I use the icons to start and stop playing a section of a recording
> > they work one time and then fail with two pop-up errors:-
> >
> >      Warning
> >      audio_device_open: pa_simple_new
> >
> > then
> >
> >      Warning
> >      Failed to open output device default:, check settings->miscellaneous
> >      for device information
> >
> >
> > If I click OK on both of these then the next time I click the Play icon
> > it plays OK.
> >
> > I have tried changing the device in settings->miscellaneous from
> > /dev/dsp to default: but it seems to have made no difference.
> >
> > While I'm about it what's the correct device to use when using gwc with
> > pulseaudio, I couldn't find any information on this.
> >

-- 
Chris Green

Re: [Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[John C. <ci...@pu...>]

I seem to remember this happened a few years ago and in my 
case was caused by the KDE
notification timeout defaulting to something too long, like 
5 seconds or so.
Because of that, the audio system really was temporarily 
busy, but for no useful reason.
After I changed the KDE event notification timeout to 1 
second, all was well from then on.
Something to check.  Not sure if other window managers have 
something similar.

John Cirillo


On 1/24/2013 8:59 AM, Chris Green wrote:
> I have just installed Gnome Wave Cleaner version 0.21-17 on my xubuntu
> 12.10 system, it works very well for me but there is one odd little
> bug I would like to clear up.
>
> When I use the icons to start and stop playing a section of a recording
> they work one time and then fail with two pop-up errors:-
>
>      Warning
>      audio_device_open: pa_simple_new
>
> then
>
>      Warning
>      Failed to open output device default:, check settings->miscellaneous
>      for device information
>
>
> If I click OK on both of these then the next time I click the Play icon
> it plays OK.
>
> I have tried changing the device in settings->miscellaneous from
> /dev/dsp to default: but it seems to have made no difference.
>
> While I'm about it what's the correct device to use when using gwc with
> pulseaudio, I couldn't find any information on this.
>

[Gwc-general] Odd error (only every other time I playback) using gwc with pulseaudio on ubuntu 12.10

[Chris G. <cl...@is...>]

I have just installed Gnome Wave Cleaner version 0.21-17 on my xubuntu
12.10 system, it works very well for me but there is one odd little
bug I would like to clear up.

When I use the icons to start and stop playing a section of a recording
they work one time and then fail with two pop-up errors:-

    Warning
    audio_device_open: pa_simple_new

then

    Warning
    Failed to open output device default:, check settings->miscellaneous
    for device information


If I click OK on both of these then the next time I click the Play icon
it plays OK.

I have tried changing the device in settings->miscellaneous from
/dev/dsp to default: but it seems to have made no difference.

While I'm about it what's the correct device to use when using gwc with
pulseaudio, I couldn't find any information on this.

-- 
Chris Green

Re: [Gwc-general] Invalid cdrdao toc file

[jeff w. <we...@ya...>]

Thanks a bunch for getting the patch into the ubuntu distro!

Cheers,
Jeff



________________________________
 From: Brian Burch <br...@pi...>
To: jeff welty <we...@ya...> 
Cc: "gwc...@li..." <gwc...@li...> 
Sent: Wednesday, April 11, 2012 7:14 AM
Subject: Re: [Gwc-general] Invalid cdrdao toc file
 
On 11/04/12 02:28, jeff welty wrote:
> At this time, I'm going hold off on another release --- cdrdao pads
> zeros at the end of the track to get the track to a multiple of a block
> length. I suspect that has always been the behaviour. So please inform
> the ubuntu folks that this is good to go.

OK, Jeff. I have generated a patch file and will upload it soon (the 
whole source for markers.c is already appended to the bug report).

> I'm guessing too that your problem CD's have to do with cd media
> quality, write speed and perhaps hardware. My personal preference has
> been to find CD-Rs manufactured by Taiyo-Yuden

Yes, that is the brand I switched to about 2 years ago. I also threw out 
the cd writer that came with my machine and invested in a much better one.

> http://www.best-dvd-burning-software-reviews.com/best-blank-dvd-media.asp
> I always burn at the lowest write speed possible, because my
> understanding is when a CD-R is burned, it literally melts a little spot
> of dye to allow the reflective layer to be exposed for the desired bit.
> The faster the cd is spinning, it seems, the more centripidal force is
> going to allow the melted dye to spread over to the next cd track, and
> the laser could have a little more trouble burning through the extra
> dye. That's just my hypothesis, I don't know for sure if it's valid, but
> I figure if I spend multiple hours preparing data for a CD, I can wait
> an extra 30 or 40 minutes for it to burn...

I agree with you, although I normally write at 4x speed (a lot less than 
the 52x maximum). I think I'll follow your recommendation in future.

Incidentally, my "bad" CD's suffer from the player being unable to read 
the toc - hence my questions. My player reports "no disk" or "err" 
status when the drawer has closed. However, this cannot be caused by 
incorrect boundaries on the toc entries, because the disk will 
eventually play if I keep putting it back in after each error.

> ---
>
> In the first implementation of song markers, I wanted the user to have
> full control on the resolution of the start and end of tracks. There may
> be cd formats in the future that aren't limited to block lengths...
>
> I'm contemplating a function to adjust the song markers to block
> segments though, because of the padding behaviour of cdrdao. If you
> wanted gapless cd's, those padded zeros might cause an audible click.
> This is going to take some extra coding and I'll want to spend a little
> more quality time on it than I currently have in my free hours outside
> of work and family time
>
> Cheers,
> Jeff
>

That sounds like a useful way to deal with this issue. I'll watch out 
for its release. Thanks again for all your help and advice.

Regards,

Brian

>
>
> ------------------------------------------------------------------------
> *From:* Brian Burch <br...@pi...>
> *To:* jeff welty <we...@ya...>
> *Cc:* "gwc...@li..."
> <gwc...@li...>
> *Sent:* Tuesday, April 10, 2012 10:05 AM
> *Subject:* Re: [Gwc-general] Invalid cdrdao toc file
>
> On 10/04/12 13:36, jeff welty wrote:
>  > Hi Brian,
>  >
>  > No problem on the questions, questions are always good. Things get
>  > better when people are asking questions :-) In fact, I just caught
>  > another tiny bug because you asked this question.
>  >
>  > Tracks can start at any arbitrary position in the wavefile, cdrdao is
>  > just going to start copying data at that exact position in the wavfile
>  > to the CD. It is the length of the track that is restricted to multiples
>  > of 588 bytes.
>  >
>  > The logic in GWC for creating the cdrdao toc file goes like this:
>  >
>  > 1) The track start position will always be *exactly* at the song marker
>  > or at 0 in the case of the first track if you use
>  > the non-paired markers method.
>  >
>  > 2) compute the requested length of the track requested by using the next
>  > song marker or last audio sample if no more song markers.
>  >
>  > 3) round the requested length to the nearest 588 sample block
>  >
>  > 4) output the start position, and the rounded length to the toc file.
>  >
>  > The logic was set up like this because I though in most cases it was
>  > probably more important to get the start of the track positioned exactly
>  > where the user wanted it, and take the rounding error at the end of the
>  > track. The worst case would miss the song marker at the end of the track
>  > by 0.0067 seconds, probably not noticeable ;-)
>  > ---
>
> Your explanation is very interesting.
>
> My CD player is quite old and fussy about disks adhering to the original
> standards, but most of my CD's play OK. However, it is temperamental
> about playing some of those I made about 18 months to 3 years ago. I
> have always thought this problem was a combination of [media quality +
> writer quality + writer speed].
>
> My more recent disks are almost always accepted first time. I wonder
> whether the "old disk" problem has something to do with the old version
> of gwc, which was happy to write a toc that didn't put tracks on
> boundaries of 588 samples? Perhaps a newer version of cdrdao has logic
> to compensate for un-rounded tracks? Perhaps my 18-month-old cd-writer
> firmware handles the toc more gracefully than the drive I used before?
>
> Whatever the reason, my current production procedure generates playable
> CD's from the non-rounded tocs that I've edited manually, although other
> people might not be so lucky.
>
>  > I just noticed all your track lengths are odd numbers. Not good, because
>  > multiples of 588 must be even numbers. The code is outputting the length
>  > as (start - end), which is wrong, it should be (start-end+1). I wonder
>  > what cdrdao does with that, does it truncate or round the length. It
>  > could cause the actual track length to be 0.018 seconds shorter than
>  > desired in the worst case if it truncates. Still not noticeable, but
>  > still wrong.
>
> Are you intending to release a patch that fixes both problems? If yes,
> would you like me to test it? Would you like me to add it to my ubuntu
> bug report when I mark its status as "patch available"?
>
>  > Thanks for your question!
>  > Jeff
>
> One more question while you have the logic in your mind... why doesn't
> gwc deal with this boundary-rounding issue at the time it is creating
> the individual song marker? As you said, 588 samples is only 18
> milliseconds, so no harm would come if it were to enforce alignment of
> the new marker on a 588-sample position. Then, if you tried to drag the
> marker along the recording, it could just jump to the next valid
> position... but perhaps that is more complex and not worth the effort of
> implementing?
>
> Regards,
>
> Brian
>
>


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Gwc-general mailing list
Gwc...@li...
https://lists.sourceforge.net/lists/listinfo/gwc-general

Re: [Gwc-general] Invalid cdrdao toc file

[Brian B. <br...@pi...>]

On 11/04/12 02:28, jeff welty wrote:
> At this time, I'm going hold off on another release --- cdrdao pads
> zeros at the end of the track to get the track to a multiple of a block
> length. I suspect that has always been the behaviour. So please inform
> the ubuntu folks that this is good to go.

OK, Jeff. I have generated a patch file and will upload it soon (the 
whole source for markers.c is already appended to the bug report).

> I'm guessing too that your problem CD's have to do with cd media
> quality, write speed and perhaps hardware. My personal preference has
> been to find CD-Rs manufactured by Taiyo-Yuden

Yes, that is the brand I switched to about 2 years ago. I also threw out 
the cd writer that came with my machine and invested in a much better one.

> http://www.best-dvd-burning-software-reviews.com/best-blank-dvd-media.asp
> I always burn at the lowest write speed possible, because my
> understanding is when a CD-R is burned, it literally melts a little spot
> of dye to allow the reflective layer to be exposed for the desired bit.
> The faster the cd is spinning, it seems, the more centripidal force is
> going to allow the melted dye to spread over to the next cd track, and
> the laser could have a little more trouble burning through the extra
> dye. That's just my hypothesis, I don't know for sure if it's valid, but
> I figure if I spend multiple hours preparing data for a CD, I can wait
> an extra 30 or 40 minutes for it to burn...

I agree with you, although I normally write at 4x speed (a lot less than 
the 52x maximum). I think I'll follow your recommendation in future.

Incidentally, my "bad" CD's suffer from the player being unable to read 
the toc - hence my questions. My player reports "no disk" or "err" 
status when the drawer has closed. However, this cannot be caused by 
incorrect boundaries on the toc entries, because the disk will 
eventually play if I keep putting it back in after each error.

> ---
>
> In the first implementation of song markers, I wanted the user to have
> full control on the resolution of the start and end of tracks. There may
> be cd formats in the future that aren't limited to block lengths...
>
> I'm contemplating a function to adjust the song markers to block
> segments though, because of the padding behaviour of cdrdao. If you
> wanted gapless cd's, those padded zeros might cause an audible click.
> This is going to take some extra coding and I'll want to spend a little
> more quality time on it than I currently have in my free hours outside
> of work and family time
>
> Cheers,
> Jeff
>

That sounds like a useful way to deal with this issue. I'll watch out 
for its release. Thanks again for all your help and advice.

Regards,

Brian

>
>
> ------------------------------------------------------------------------
> *From:* Brian Burch <br...@pi...>
> *To:* jeff welty <we...@ya...>
> *Cc:* "gwc...@li..."
> <gwc...@li...>
> *Sent:* Tuesday, April 10, 2012 10:05 AM
> *Subject:* Re: [Gwc-general] Invalid cdrdao toc file
>
> On 10/04/12 13:36, jeff welty wrote:
>  > Hi Brian,
>  >
>  > No problem on the questions, questions are always good. Things get
>  > better when people are asking questions :-) In fact, I just caught
>  > another tiny bug because you asked this question.
>  >
>  > Tracks can start at any arbitrary position in the wavefile, cdrdao is
>  > just going to start copying data at that exact position in the wavfile
>  > to the CD. It is the length of the track that is restricted to multiples
>  > of 588 bytes.
>  >
>  > The logic in GWC for creating the cdrdao toc file goes like this:
>  >
>  > 1) The track start position will always be *exactly* at the song marker
>  > or at 0 in the case of the first track if you use
>  > the non-paired markers method.
>  >
>  > 2) compute the requested length of the track requested by using the next
>  > song marker or last audio sample if no more song markers.
>  >
>  > 3) round the requested length to the nearest 588 sample block
>  >
>  > 4) output the start position, and the rounded length to the toc file.
>  >
>  > The logic was set up like this because I though in most cases it was
>  > probably more important to get the start of the track positioned exactly
>  > where the user wanted it, and take the rounding error at the end of the
>  > track. The worst case would miss the song marker at the end of the track
>  > by 0.0067 seconds, probably not noticeable ;-)
>  > ---
>
> Your explanation is very interesting.
>
> My CD player is quite old and fussy about disks adhering to the original
> standards, but most of my CD's play OK. However, it is temperamental
> about playing some of those I made about 18 months to 3 years ago. I
> have always thought this problem was a combination of [media quality +
> writer quality + writer speed].
>
> My more recent disks are almost always accepted first time. I wonder
> whether the "old disk" problem has something to do with the old version
> of gwc, which was happy to write a toc that didn't put tracks on
> boundaries of 588 samples? Perhaps a newer version of cdrdao has logic
> to compensate for un-rounded tracks? Perhaps my 18-month-old cd-writer
> firmware handles the toc more gracefully than the drive I used before?
>
> Whatever the reason, my current production procedure generates playable
> CD's from the non-rounded tocs that I've edited manually, although other
> people might not be so lucky.
>
>  > I just noticed all your track lengths are odd numbers. Not good, because
>  > multiples of 588 must be even numbers. The code is outputting the length
>  > as (start - end), which is wrong, it should be (start-end+1). I wonder
>  > what cdrdao does with that, does it truncate or round the length. It
>  > could cause the actual track length to be 0.018 seconds shorter than
>  > desired in the worst case if it truncates. Still not noticeable, but
>  > still wrong.
>
> Are you intending to release a patch that fixes both problems? If yes,
> would you like me to test it? Would you like me to add it to my ubuntu
> bug report when I mark its status as "patch available"?
>
>  > Thanks for your question!
>  > Jeff
>
> One more question while you have the logic in your mind... why doesn't
> gwc deal with this boundary-rounding issue at the time it is creating
> the individual song marker? As you said, 588 samples is only 18
> milliseconds, so no harm would come if it were to enforce alignment of
> the new marker on a 588-sample position. Then, if you tried to drag the
> marker along the recording, it could just jump to the next valid
> position... but perhaps that is more complex and not worth the effort of
> implementing?
>
> Regards,
>
> Brian
>
>

Re: [Gwc-general] Invalid cdrdao toc file

[jeff w. <we...@ya...>]

At this time, I'm going hold off on another release --- cdrdao pads zeros at the end of the track to get the track to a multiple of a block length.  I suspect that has always been the behaviour.  So please inform the ubuntu folks that this is good to go.

I'm guessing too that your problem CD's have to do with cd media quality, write speed and perhaps hardware.  My personal preference has been to find CD-Rs manufactured by Taiyo-Yuden

http://www.best-dvd-burning-software-reviews.com/best-blank-dvd-media.asp

I always burn at the lowest write speed possible, because my understanding is when a CD-R is burned, it literally melts a little spot of dye to allow the reflective layer to be exposed for the desired bit.  The faster the cd is spinning, it seems, the more centripidal force is going to allow the melted dye to spread over to the next cd track, and the laser could have a little more trouble burning through the extra dye.  That's just my hypothesis, I don't know for sure if it's valid, but I figure if I spend multiple hours preparing data for a CD, I can wait an extra 30 or 40 minutes for it to burn...

---


In the first implementation of song markers, I wanted the user to have full control on the resolution of the start and end of tracks.  There may be cd formats in the future that aren't limited to block lengths...

I'm contemplating a function to adjust the song markers to block segments though, because of the padding behaviour of cdrdao.  If you wanted gapless cd's, those padded zeros might cause an audible click.  This is going to take some extra coding and I'll want to spend a little more quality time on it than I currently have in my free hours outside of work and family time.


Cheers,
Jeff






________________________________
 From: Brian Burch <br...@pi...>
To: jeff welty <we...@ya...> 
Cc: "gwc...@li..." <gwc...@li...> 
Sent: Tuesday, April 10, 2012 10:05 AM
Subject: Re: [Gwc-general] Invalid cdrdao toc file
 
On 10/04/12 13:36, jeff welty wrote:
> Hi Brian,
> 
> No problem on the questions, questions are always good. Things get
> better when people are asking questions :-) In fact, I just caught
> another tiny bug because you asked this question.
> 
> Tracks can start at any arbitrary position in the wavefile, cdrdao is
> just going to start copying data at that exact position in the wavfile
> to the CD. It is the length of the track that is restricted to multiples
> of 588 bytes.
> 
> The logic in GWC for creating the cdrdao toc file goes like this:
> 
> 1) The track start position will always be *exactly* at the song marker
> or at 0 in the case of the first track if you use
> the non-paired markers method.
> 
> 2) compute the requested length of the track requested by using the next
> song marker or last audio sample if no more song markers.
> 
> 3) round the requested length to the nearest 588 sample block
> 
> 4) output the start position, and the rounded length to the toc file.
> 
> The logic was set up like this because I though in most cases it was
> probably more important to get the start of the track positioned exactly
> where the user wanted it, and take the rounding error at the end of the
> track. The worst case would miss the song marker at the end of the track
> by 0.0067 seconds, probably not noticeable ;-)
> ---

Your explanation is very interesting.

My CD player is quite old and fussy about disks adhering to the original standards, but most of my CD's play OK. However, it is temperamental about playing some of those I made about 18 months to 3 years ago. I have always thought this problem was a combination of [media quality + writer quality + writer speed].

My more recent disks are almost always accepted first time. I wonder whether the "old disk" problem has something to do with the old version of gwc, which was happy to write a toc that didn't put tracks on boundaries of 588 samples? Perhaps a newer version of cdrdao has logic to compensate for un-rounded tracks? Perhaps my 18-month-old cd-writer firmware handles the toc more gracefully than the drive I used before?

Whatever the reason, my current production procedure generates playable CD's from the non-rounded tocs that I've edited manually, although other people might not be so lucky.

> I just noticed all your track lengths are odd numbers. Not good, because
> multiples of 588 must be even numbers. The code is outputting the length
> as (start - end), which is wrong, it should be (start-end+1). I wonder
> what cdrdao does with that, does it truncate or round the length. It
> could cause the actual track length to be 0.018 seconds shorter than
> desired in the worst case if it truncates. Still not noticeable, but
> still wrong.

Are you intending to release a patch that fixes both problems? If yes, would you like me to test it? Would you like me to add it to my ubuntu bug report when I mark its status as "patch available"?

> Thanks for your question!
> Jeff

One more question while you have the logic in your mind... why doesn't gwc deal with this boundary-rounding issue at the time it is creating the individual song marker? As you said, 588 samples is only 18 milliseconds, so no harm would come if it were to enforce alignment of the new marker on a 588-sample position. Then, if you tried to drag the marker along the recording, it could just jump to the next valid position... but perhaps that is more complex and not worth the effort of implementing?

Regards,

Brian

Re: [Gwc-general] Invalid cdrdao toc file

[Brian B. <br...@pi...>]

On 10/04/12 13:36, jeff welty wrote:
> Hi Brian,
>
> No problem on the questions, questions are always good. Things get
> better when people are asking questions :-) In fact, I just caught
> another tiny bug because you asked this question.
>
> Tracks can start at any arbitrary position in the wavefile, cdrdao is
> just going to start copying data at that exact position in the wavfile
> to the CD. It is the length of the track that is restricted to multiples
> of 588 bytes.
>
> The logic in GWC for creating the cdrdao toc file goes like this:
>
> 1) The track start position will always be *exactly* at the song marker
> or at 0 in the case of the first track if you use
> the non-paired markers method.
>
> 2) compute the requested length of the track requested by using the next
> song marker or last audio sample if no more song markers.
>
> 3) round the requested length to the nearest 588 sample block
>
> 4) output the start position, and the rounded length to the toc file.
>
> The logic was set up like this because I though in most cases it was
> probably more important to get the start of the track positioned exactly
> where the user wanted it, and take the rounding error at the end of the
> track. The worst case would miss the song marker at the end of the track
> by 0.0067 seconds, probably not noticeable ;-)
> ---

Your explanation is very interesting.

My CD player is quite old and fussy about disks adhering to the original 
standards, but most of my CD's play OK. However, it is temperamental 
about playing some of those I made about 18 months to 3 years ago. I 
have always thought this problem was a combination of [media quality + 
writer quality + writer speed].

My more recent disks are almost always accepted first time. I wonder 
whether the "old disk" problem has something to do with the old version 
of gwc, which was happy to write a toc that didn't put tracks on 
boundaries of 588 samples? Perhaps a newer version of cdrdao has logic 
to compensate for un-rounded tracks? Perhaps my 18-month-old cd-writer 
firmware handles the toc more gracefully than the drive I used before?

Whatever the reason, my current production procedure generates playable 
CD's from the non-rounded tocs that I've edited manually, although other 
people might not be so lucky.

> I just noticed all your track lengths are odd numbers. Not good, because
> multiples of 588 must be even numbers. The code is outputting the length
> as (start - end), which is wrong, it should be (start-end+1). I wonder
> what cdrdao does with that, does it truncate or round the length. It
> could cause the actual track length to be 0.018 seconds shorter than
> desired in the worst case if it truncates. Still not noticeable, but
> still wrong.

Are you intending to release a patch that fixes both problems? If yes, 
would you like me to test it? Would you like me to add it to my ubuntu 
bug report when I mark its status as "patch available"?

> Thanks for your question!
> Jeff

One more question while you have the logic in your mind... why doesn't 
gwc deal with this boundary-rounding issue at the time it is creating 
the individual song marker? As you said, 588 samples is only 18 
milliseconds, so no harm would come if it were to enforce alignment of 
the new marker on a 588-sample position. Then, if you tried to drag the 
marker along the recording, it could just jump to the next valid 
position... but perhaps that is more complex and not worth the effort of 
implementing?

Regards,

Brian

Re: [Gwc-general] Invalid cdrdao toc file

[jeff w. <we...@ya...>]

Hi Brian,

No problem on the questions, questions are always good.  Things get better when people are asking questions :-) In fact, I just caught another tiny bug because you asked this question.


Tracks can start at any arbitrary position in the wavefile, cdrdao is just going to start copying data at that exact position in the wavfile to the CD.  It is the length of the track that is restricted to multiples of 588 bytes.


The logic in GWC for creating the cdrdao toc file goes like this:

1) The track start position will always be *exactly* at the song marker or at 0 in the case of the first track if you use
the non-paired markers method.  


2) compute the requested length of the track requested by using the next song marker or last audio sample if no more song markers.

3) round the requested length to the nearest 588 sample block

4) output the start position, and the rounded length to the toc file.


The logic was set up like this because I though in most cases it was probably more important to get the start of the track positioned exactly where the user wanted it, and take the rounding error at the end of the track. The worst case would miss the song marker at the end of the track by 0.0067 seconds, probably not noticeable ;-)
---

I just noticed all your track lengths are odd numbers.  Not good, because multiples of 588 must be even numbers.  The code is outputting the length as (start - end), which is wrong, it should be (start-end+1).  I wonder what cdrdao does with that, does it truncate or round the length.  It could cause the actual track length to be 0.018 seconds shorter than desired in the worst case if it truncates.  Still not noticeable, but still wrong.

Thanks for your question!
Jeff



________________________________
 From: Brian Burch <br...@pi...>
To: jeff welty <we...@ya...> 
Cc: "gwc...@li..." <gwc...@li...> 
Sent: Tuesday, April 10, 2012 2:42 AM
Subject: Re: [Gwc-general] Invalid cdrdao toc file
 
On 09/04/12 23:51, jeff welty wrote:
> Hi Brian,
>
> I didn't get any new toc files in your message...
>
> I have tried both methods for creating the toc files, and it works
> perfectly for me.
>
> Are the differences you are seeing less than 588 samples? If so, that is
> expected because of the restriction that cdrdao tracks have to be
> multiples of audio blocks in length.

Sorry, Jeff! When I sent the last email I forgot to include the toc file 
built by your new version of markers.c. It is in-line at the end of my 
comments.

Following your advice, I checked the differences and can see they are 
smaller than 588 samples, i.e. the two "gaps" are 262 and 76 samples 
respectively.

I apologise for doubting you. You had mentioned this restriction earlier 
but I had forgotten it.

I /thought/ you meant gwc would always start a new track on a boundary 
that is a multiple of 588. I grepped the source for 588 and found it 
only only in markers.c, defining the constant SONG_BLOCK_LEN. I could 
only find that constant used in two routines - move_song_marker and 
mark_songs. Both routines appear to be rounding the song marker 
boundaries to make them multiples of 588.

I don't currently have a debugging environment to follow the logic any 
deeper, but my calculator says /none/ of the sample counters in the new 
toc are multiples of 588 (except zero, of course).

I apologise for being a nuisance, but would you mind explaining to me 
how the rule has been applied in this particular case?


CD_TEXT {
    LANGUAGE_MAP {
       0: EN
    }
    LANGUAGE 0 {
       TITLE "The Doors"
       MESSAGE "Brians clean test"
    }
}
TRACK AUDIO
    CD_TEXT {
       LANGUAGE 0 {
          TITLE "part 1"
          MESSAGE ""
       }
    }
    FILE "/home/brian/gwc-test/export.wav" 0 38342303
TRACK AUDIO
    CD_TEXT {
       LANGUAGE 0 {
          TITLE "part 2"
          MESSAGE ""
       }
    }
    FILE "/home/brian/gwc-test/export.wav" 38342565 28204595
TRACK AUDIO
    CD_TEXT {
       LANGUAGE 0 {
          TITLE "part 3"
          MESSAGE ""
       }
    }
    FILE "/home/brian/gwc-test/export.wav" 66547236 50606219

> Jeff
>
> ------------------------------------------------------------------------
> *From:* Brian Burch <br...@pi...>
> *To:* "gwc...@li..."
> <gwc...@li...>
> *Sent:* Monday, April 9, 2012 2:40 AM
> *Subject:* Re: [Gwc-general] Invalid cdrdao toc file
>
> On 08/04/12 23:36, jeff welty wrote:
>  > Hi Brian,
>  >
>  > Thanks very much for the more detailed info. I was able to reproduce the
>  > problem, and it is one nasty bug. I guess everyone must've switched over
>  > to using the song marker pairs. BTW, the marker pairs idea allows you to
>  > have gaps between songs, some lead-in audio (like when the the needle
>  > hits the vinyl ;-) ), and some trail out audio. It gives you more
>  > control on what segments of audio you want to appear on the CD tracks.
>  >
>  > Another bit of important trivia, audio tracks must be integral numbers
>  > of audio blocks, which are 588 samples in length, so if you are doing
>  > math with song markers, you'll find small differences because GWC will
>  > create the cdrdao file with the track lengths to the nearest audio block.
>  >
>  > I have patched up the markers.c source code, and it is attached.
>
> Sorry to bring bad news, Jeff, but I have just built and tested your new
> source module. It looks to me as if you have nearly fixed the bug, but
> there is still a bit more to do.
>
> It seems to me that you haven't disabled the marker pair "track
> separator logic" and so the toc is not inclusive of every sample...
>
> i.e. start_track_n+1 != (start_track_n + length_track_n)
>
> Here is the toc built by your new code using the same wav and .gwc file
> as my test files below. You should compare it to the toc I built by hand
> to see what I think ought to be the "right answer".
>
> I won't start debugging your code unless you are too busy to do it
> yourself - I am sure you are so familiar with it you'll come up with a
> fix in a fraction of the time it would take me!
>
> Regards,
>
> Brian
>


------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
Gwc-general mailing list
Gwc...@li...
https://lists.sourceforge.net/lists/listinfo/gwc-general

Re: [Gwc-general] Invalid cdrdao toc file

[Brian B. <br...@pi...>]

On 09/04/12 23:51, jeff welty wrote:
> Hi Brian,
>
> I didn't get any new toc files in your message...
>
> I have tried both methods for creating the toc files, and it works
> perfectly for me.
>
> Are the differences you are seeing less than 588 samples? If so, that is
> expected because of the restriction that cdrdao tracks have to be
> multiples of audio blocks in length.

Sorry, Jeff! When I sent the last email I forgot to include the toc file 
built by your new version of markers.c. It is in-line at the end of my 
comments.

Following your advice, I checked the differences and can see they are 
smaller than 588 samples, i.e. the two "gaps" are 262 and 76 samples 
respectively.

I apologise for doubting you. You had mentioned this restriction earlier 
but I had forgotten it.

I /thought/ you meant gwc would always start a new track on a boundary 
that is a multiple of 588. I grepped the source for 588 and found it 
only only in markers.c, defining the constant SONG_BLOCK_LEN. I could 
only find that constant used in two routines - move_song_marker and 
mark_songs. Both routines appear to be rounding the song marker 
boundaries to make them multiples of 588.

I don't currently have a debugging environment to follow the logic any 
deeper, but my calculator says /none/ of the sample counters in the new 
toc are multiples of 588 (except zero, of course).

I apologise for being a nuisance, but would you mind explaining to me 
how the rule has been applied in this particular case?


CD_TEXT {
    LANGUAGE_MAP {
       0: EN
    }
    LANGUAGE 0 {
       TITLE "The Doors"
       MESSAGE "Brians clean test"
    }
}
TRACK AUDIO
    CD_TEXT {
       LANGUAGE 0 {
          TITLE "part 1"
          MESSAGE ""
       }
    }
    FILE "/home/brian/gwc-test/export.wav" 0 38342303
TRACK AUDIO
    CD_TEXT {
       LANGUAGE 0 {
          TITLE "part 2"
          MESSAGE ""
       }
    }
    FILE "/home/brian/gwc-test/export.wav" 38342565 28204595
TRACK AUDIO
    CD_TEXT {
       LANGUAGE 0 {
          TITLE "part 3"
          MESSAGE ""
       }
    }
    FILE "/home/brian/gwc-test/export.wav" 66547236 50606219

> Jeff
>
> ------------------------------------------------------------------------
> *From:* Brian Burch <br...@pi...>
> *To:* "gwc...@li..."
> <gwc...@li...>
> *Sent:* Monday, April 9, 2012 2:40 AM
> *Subject:* Re: [Gwc-general] Invalid cdrdao toc file
>
> On 08/04/12 23:36, jeff welty wrote:
>  > Hi Brian,
>  >
>  > Thanks very much for the more detailed info. I was able to reproduce the
>  > problem, and it is one nasty bug. I guess everyone must've switched over
>  > to using the song marker pairs. BTW, the marker pairs idea allows you to
>  > have gaps between songs, some lead-in audio (like when the the needle
>  > hits the vinyl ;-) ), and some trail out audio. It gives you more
>  > control on what segments of audio you want to appear on the CD tracks.
>  >
>  > Another bit of important trivia, audio tracks must be integral numbers
>  > of audio blocks, which are 588 samples in length, so if you are doing
>  > math with song markers, you'll find small differences because GWC will
>  > create the cdrdao file with the track lengths to the nearest audio block.
>  >
>  > I have patched up the markers.c source code, and it is attached.
>
> Sorry to bring bad news, Jeff, but I have just built and tested your new
> source module. It looks to me as if you have nearly fixed the bug, but
> there is still a bit more to do.
>
> It seems to me that you haven't disabled the marker pair "track
> separator logic" and so the toc is not inclusive of every sample...
>
> i.e. start_track_n+1 != (start_track_n + length_track_n)
>
> Here is the toc built by your new code using the same wav and .gwc file
> as my test files below. You should compare it to the toc I built by hand
> to see what I think ought to be the "right answer".
>
> I won't start debugging your code unless you are too busy to do it
> yourself - I am sure you are so familiar with it you'll come up with a
> fix in a fraction of the time it would take me!
>
> Regards,
>
> Brian
>

Re: [Gwc-general] Invalid cdrdao toc file

[jeff w. <we...@ya...>]

Hi Brian,

I didn't get any new toc files in your message...

I have tried both methods for creating the toc files, and it works perfectly for me.


Are the differences you are seeing less than 588 samples?  If so, that is expected because of the restriction that cdrdao tracks have to be multiples of audio blocks in length.


Jeff



________________________________
 From: Brian Burch <br...@pi...>
To: "gwc...@li..." <gwc...@li...> 
Sent: Monday, April 9, 2012 2:40 AM
Subject: Re: [Gwc-general] Invalid cdrdao toc file
 
On 08/04/12 23:36, jeff welty wrote:
> Hi Brian,
>
> Thanks very much for the more detailed info. I was able to reproduce the
> problem, and it is one nasty bug. I guess everyone must've switched over
> to using the song marker pairs. BTW, the marker pairs idea allows you to
> have gaps between songs, some lead-in audio (like when the the needle
> hits the vinyl ;-) ), and some trail out audio. It gives you more
> control on what segments of audio you want to appear on the CD tracks.
>
> Another bit of important trivia, audio tracks must be integral numbers
> of audio blocks, which are 588 samples in length, so if you are doing
> math with song markers, you'll find small differences because GWC will
> create the cdrdao file with the track lengths to the nearest audio block.
>
> I have patched up the markers.c source code, and it is attached.

Sorry to bring bad news, Jeff, but I have just built and tested your new 
source module. It looks to me as if you have nearly fixed the bug, but 
there is still a bit more to do.

It seems to me that you haven't disabled the marker pair "track 
separator logic" and so the toc is not inclusive of every sample...

i.e. start_track_n+1 != (start_track_n + length_track_n)

Here is the toc built by your new code using the same wav and .gwc file 
as my test files below. You should compare it to the toc I built by hand 
to see what I think ought to be the "right answer".

I won't start debugging your code unless you are too busy to do it 
yourself - I am sure you are so familiar with it you'll come up with a 
fix in a fraction of the time it would take me!

Regards,

Brian

Re: [Gwc-general] Invalid cdrdao toc file

[Brian B. <br...@pi...>]

On 08/04/12 23:36, jeff welty wrote:
> Hi Brian,
>
> Thanks very much for the more detailed info. I was able to reproduce the
> problem, and it is one nasty bug. I guess everyone must've switched over
> to using the song marker pairs. BTW, the marker pairs idea allows you to
> have gaps between songs, some lead-in audio (like when the the needle
> hits the vinyl ;-) ), and some trail out audio. It gives you more
> control on what segments of audio you want to appear on the CD tracks.
>
> Another bit of important trivia, audio tracks must be integral numbers
> of audio blocks, which are 588 samples in length, so if you are doing
> math with song markers, you'll find small differences because GWC will
> create the cdrdao file with the track lengths to the nearest audio block.
>
> I have patched up the markers.c source code, and it is attached.

Sorry to bring bad news, Jeff, but I have just built and tested your new 
source module. It looks to me as if you have nearly fixed the bug, but 
there is still a bit more to do.

It seems to me that you haven't disabled the marker pair "track 
separator logic" and so the toc is not inclusive of every sample...

i.e. start_track_n+1 != (start_track_n + length_track_n)

Here is the toc built by your new code using the same wav and .gwc file 
as my test files below. You should compare it to the toc I built by hand 
to see what I think ought to be the "right answer".

I won't start debugging your code unless you are too busy to do it 
yourself - I am sure you are so familiar with it you'll come up with a 
fix in a fraction of the time it would take me!

Regards,

Brian
>
> I'll see if I can get hold of the ubuntu maintainers, they'll really
> want to have this bugfix!
>
> Thank you again!
> Jeff
>
> ------------------------------------------------------------------------
> *From:* Brian Burch <br...@pi...>
> *To:* "gwc...@li..."
> <gwc...@li...>
> *Sent:* Sunday, April 8, 2012 1:16 PM
> *Subject:* Re: [Gwc-general] Invalid cdrdao toc file
>
> On 08/04/12 03:19, jeff welty wrote:
>  > Hi Brian,
>
> Hi Jeff,
>
> I'm really pleased that you picked up my question so quickly and I
> really appreciate you helping me.
>
>  > Literally nothing has changed in the code that handles the song markers
>  > and creates the cdrdao toc file since before version 0.21-10.
>
> I wish I had noticed which version of gwc was running the last time I
> used it successfully. If it turns out to be important, I will dig
> through my backups to identify it.
>
> However, I'm fairly confident ubuntu studio was offering something older
> than 0.21-10 in its repository about 2 years ago.
>
>
>  > It sounds to me like you may have inadvertantly used the
>  > "Create cdrdao toc file, using marker pairs, As..."
>  > version of creating the toc file? That causes the first track to start
>  > not at sample 0, but rather starts the first track at the position of
>  > the first song marker.
>
> Yes, I thought of that too because I was intrigued by the menu items
> that I didn't recognise from the previous version that I used.
>
> I am sure I didn't make that mistake, but to be certain I started from
> scratch (see below).
>
>  > I am pretty sure you did find a bug though, I'll bet you had an odd
>  > number of song markers, and gwc read whatever garbage was on the stack
>  > to find the end position for the last track.
>  > Can you double check that gwc does create a valid toc file for your
>  > project with the "Create cdrdao toc file As..." option, just in case you
>  > did click the wrong one?
>
> I created a fresh directory and copied a single, large wav file into it
> (i.e. there were no pre-existing blah.wav.gwc or blah.toc files. I split
> it arbitrarily into three tracks.
>
> Here is the cdrdao.toc created by gwc:
>
> CD_TEXT {
> LANGUAGE_MAP {
> 0: EN
> }
> LANGUAGE 0 {
> TITLE "The Doors"
> MESSAGE "Brians clean test"
> }
> }
> TRACK AUDIO
> CD_TEXT {
> LANGUAGE 0 {
> TITLE "part 1"
> MESSAGE ""
> }
> }
> FILE "/home/brian/gwc-test/export.wav" 38342565 28204595
> TRACK AUDIO
> CD_TEXT {
> LANGUAGE 0 {
> TITLE "part 2"
> MESSAGE ""
> }
> }
> FILE "/home/brian/gwc-test/export.wav" 66547236 50606219
> TRACK AUDIO
> CD_TEXT {
> LANGUAGE 0 {
> TITLE "part 3"
> MESSAGE ""
> }
> }
> FILE "/home/brian/gwc-test/export.wav" 0 117153707
>
>
> ... and here is the "correct" version that I created from the
> information available in the gwc window using the same song markers:
>
> CD_TEXT {
> LANGUAGE_MAP {
> 0: EN
> }
> LANGUAGE 0 {
> TITLE "The Doors"
> MESSAGE "Brians clean test, manual assignment of boundaries"
> }
> }
> TRACK AUDIO
> CD_TEXT {
> LANGUAGE 0 {
> TITLE "part 1"
> MESSAGE ""
> }
> }
> FILE "/home/brian/gwc-test/export.wav" 0 38342566
> TRACK AUDIO
> CD_TEXT {
> LANGUAGE 0 {
> TITLE "part 2"
> MESSAGE ""
> }
> }
> FILE "/home/brian/gwc-test/export.wav" 38342566 28204672
> TRACK AUDIO
> CD_TEXT {
> LANGUAGE 0 {
> TITLE "part 3"
> MESSAGE ""
> }
> }
> FILE "/home/brian/gwc-test/export.wav" 66547238 50606490
> // total number of samples calculated: 117153728
> // total number of samples from gwc : 117153727
>
>
> Obviously, the first track ought to start with sample zero and it
> doesn't. In fact, if you look carefully it seems "first" track has been
> built with the start and length values required to define the real
> SECOND track!
>
> The "second" track carries the start and length of the real THIRD track.
>
> The "third" track starts with sample zero, and its length is /nearly/
> the same as the number of samples in the entire file.
>
> I definitely added song markers, NOT song marker pairs. I definitely
> saved the toc with the correct option, not trying to use marker pairs.
>
> However, just in case it is significant, I used VIEW -> select all
> before creating the toc file. My previous version required EDIT ->
> select all, but this no longer exists.
>
> I would appreciate your thoughts on my latest experiment and evidence.
> If you think it is important, I will find out which version of gwc last
> worked OK for me using the same procedure.
>
> n.b. I do NOT place a song marker before the first sample... perhaps I
> should try that as an experiment?
>
>  > Thanks very much for the report, regardless. It's good to know GWC is
>  > still getting some use...
>
> I think it is a brilliant tool and wouldn't use anything else to clean
> up a noisy vinyl recording. I'm very pleased someone is still watching
> over it.
>
> Regards,
>
> Brian
>
>  > Jeff
>  >
>  > ------------------------------------------------------------------------
>  > *From:* Brian Burch <br...@pi... <mailto:br...@pi...>>
>  > *To:* gwc...@li...
> <mailto:gwc...@li...>
>  > *Sent:* Thursday, April 5, 2012 9:34 AM
>  > *Subject:* [Gwc-general] Invalid cdrdao toc file
>  >
>  > I am using GWC 0.21-16, which is currently shipped with the ubuntu
>  > studio 12.04 precise pangolin beta 2. It is also the current version
>  > with my production ubuntu studio 11.10 system.
>  >
>  > It isn't strictly relevant, but I convert vinyl to digital using an
>  > Edirol FA-66 firewire device controlled by jackd and captured by Ardour.
>  >
>  > I use Ardour to export a single wav file for the entire vinyl album and
>  > then use gwc to clean up the recording.
>  >
>  > When I have a wav file that I like, I then manually mark the boundary of
>  > each track with "Markers -> Add Song Marker". Finally, I "View ->
>  > SelectAll" and then "File -> Create cdrdao toc file As...".
>  >
>  > I manually fill in the album and track names on the toc dialogue and
>  > save the file. I write a new CD with "cdrdao --speed 4 export.toc". This
>  > is a procedure I've been following for several years without any
> problems.
>  >
>  > However, since I upgraded gwc to 0.21-16, cdrdao has complained about
>  > the toc files and refused to write the cd as follows:
>  >
>  > brian@schizo:~/WeatherReport-sportinLife/export$ cdrdao write --speed 4
>  > export.toc
>  > Cdrdao version 1.2.3 - (C) Andreas Mueller <an...@da...
> <mailto:an...@da...>
>  > <mailto:an...@da... <mailto:an...@da...>>>
>  > ERROR: Track 7: Requested length (89737555 + 12992447 samples) exceeds
>  > length of audio file
>  > "/home/brian/WeatherReport-sportinLife/export/export.wav" (102729733
>  > samples at offset 0).
>  > ERROR: The toc check function detected at least one warning.
>  > ERROR: If you record this toc the resulting CD might be unusable
>  > ERROR: or the recording process might abort with error.
>  > ERROR: Use option --force to ignore the warnings.
>  > ERROR: Toc file "export.toc" is inconsistent.
>  >
>  > The toc file is fairly badly wrong - the first track does not even start
>  > with sample number zero!
>  >
>  > I took a copy of the bad toc file and manually edited all the track
>  > start and length sample counters. I took the actual boundaries by
>  > displaying the sample counters for each of the song markers displayed by
>  > gwc, so we were working off the same wav file and analysis. My manual
>  > sample counters were very different to those automatically generated
> by gwc.
>  >
>  > I've googled, but not found anything relevant. Am I using the
>  > appropriate dialogue to create my toc file on this release of gwc (i.e.
>  > this is a user error), or does this sound like a bug? (I notice you've
>  > added new toc file features in recent releases, so perhaps this is
>  > collateral damage.)
>  >
>  > I don't know whether your mailing list strips attachments, so I won't
>  > send the two files at this time. I'm happy to send them in-line if
>  > anyone feels they would help in diagnosis.
>  >
>  > Obviously this isn't urgent for me because I have a tedious but viable
>  > bypass for the problem. However, this version of gwc is being pushed out
>  > as 0.21.16~dfsg-3build (precise) and 0.21.16~dfsg-3 (oneiric) from the
>  > ubuntu repositories, so it has a wide exposure!
>  >
>  > Regards,
>  >
>  > Brian Burch
>  >
>  >
>  >
> ------------------------------------------------------------------------------
>  > Better than sec? Nothing is better than sec when it comes to
>  > monitoring Big Data applications. Try Boundary one-second
>  > resolution app monitoring today. Free.
>  > http://p.sf.net/sfu/Boundary-dev2dev
>  > _______________________________________________
>  > Gwc-general mailing list
>  > Gwc...@li...
> <mailto:Gwc...@li...>
> <mailto:Gwc...@li...
> <mailto:Gwc...@li...>>
>  > https://lists.sourceforge.net/lists/listinfo/gwc-general
>  >
>  >
>
>
> ------------------------------------------------------------------------------
> For Developers, A Lot Can Happen In A Second.
> Boundary is the first to Know...and Tell You.
> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
> http://p.sf.net/sfu/Boundary-d2dvs2
> _______________________________________________
> Gwc-general mailing list
> Gwc...@li... <mailto:Gwc...@li...>
> https://lists.sourceforge.net/lists/listinfo/gwc-general
>
>

[Gwc-general] gwc 0.21-17 released

[jeff w. <we...@ya...>]

Many thanks to Brian Burch for the bug report on cdrdao toc file generation.

Also thanks to quadrispro for the patch to create undo and *.gwc without exec permissions.

Also, thanks to me :-) or not :-(, depending on your point of view, there was a pretty awful bug in using the alsa sound driver in 0.21-16, that slipped by as a side-affect when I was testing the pulse audio driver.

Jame Tappin, I see you found problems with the install locations.  It's been a while since I understood the details of how that all works, the configure script automagically assigns some prefixs for bin, doc, etc files.  I may need to rebuild the configure script, but will have to dig around a little to figure it out.

Enjoy,
Jeff


________________________________