Menu
▾
▴
gwc-general
|
From: Brian B. <br...@pi...> - 2012-04-05 16:52:00
|
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...> 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 |
|
From: jeff w. <we...@ya...> - 2012-04-08 02:19:24
|
Hi Brian, Literally nothing has changed in the code that handles the song markers and creates the cdrdao toc file since before version 0.21-10. 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. 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? Thanks very much for the report, regardless. It's good to know GWC is still getting some use... Jeff ________________________________ From: Brian Burch <br...@pi...> To: 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...> 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... https://lists.sourceforge.net/lists/listinfo/gwc-general |
|
From: <lin...@te...> - 2012-04-09 01:02:31
|
Quoting jeff welty <we...@ya...>: > It's good to know GWC is still getting some use... I also still use it a good bit. Its most recent "major" workout was processing the WAV files for my CD entitled "Christmas at 78 rpm, con alcuna licenza." I had long wanted to put together such a thing, and finally got it done in time for last Christmas. Most of the 78s went through gwc with pretty conservative settings. It's the best of its kind I've tried, not that I've tried dozens. Thanks for keeping it going! Howard Sanner lin...@te... |
|
From: Brian B. <br...@pi...> - 2012-04-08 20:16:33
|
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...>
> *To:* 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...>>
> 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...>
> https://lists.sourceforge.net/lists/listinfo/gwc-general
>
>
|
|
From: jeff w. <we...@ya...> - 2012-04-08 22:36:21
|
/*****************************************************************************
* Gnome Wave Cleaner Version 0.19
* Copyright (C) 2001 Jeffrey J. Welty
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version 2
* of the License, or (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, write to the Free Software
* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
*******************************************************************************/
/* markers.c */
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <stdarg.h>
#include <libgen.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <sys/time.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <signal.h>
#include <gnome.h>
#include "gtkledbar.h"
#include "gwc.h"
long cdtext_length;
char *cdtext_data = NULL;
/* The file selection widget and the string to store the chosen filename */
GtkWidget *file_selector;
gchar *selected_filename;
gchar save_cdrdao_toc_filename[255] ;
extern long num_song_markers, song_markers[] ;
extern gchar wave_filename[] ;
extern struct sound_prefs prefs ;
extern struct view audio_view;
extern double song_key_highlight_interval ;
extern double song_mark_silence ;
char *find_text(long length,char *data, char *str) {
char *ret = NULL;
char *end = data + length;
int len;
while (data < end && ret == NULL) {
len = strlen(data);
if (strcmp(data, str) == 0) {
ret = data + len + 1;
} else {
data = data + len + 1;
/* Skip field value */
len = strlen(data);
data = data + len + 1;
}
}
return ret;
}
int only_blank(char *str)
{
while (*str != 0) {
if (*str++ != ' ')
return 0;
}
return 1;
}
static int use_song_marker_pairs ; /* song markers are positioned at start AND end of each song? */
#define ARRAYSIZE(x) (sizeof(x) / sizeof(x[0]))
/* CD Tracks must be multiple of 588 or they will be padded with zeros */
#define SONG_BLOCK_LEN 588
void cdrdao_toc_info(char *filename)
{
GtkWidget *dlg ;
GtkWidget *dialog_table ;
GtkWidget *song_table ;
int dres ;
int row = 0;
struct {
char *title;
char *fieldid;
char *init;
int always_write;
GtkWidget *widget;
} album_info[] =
{
{"Language", "LANGUAGE", "EN", 1, NULL}, /* This is special and must be first */
{"Title", "TITLE", "", 1, NULL},
{"Performer", "PERFORMER", "", 0, NULL},
{"Songwriter", "SONGWRITER", "", 0, NULL},
{"Arranger", "ARRANGER", "", 0, NULL},
{"Composer", "COMPOSER", "", 0, NULL},
{"Disc_ID", "DISC_ID", "", 0, NULL},
{"Message", "MESSAGE", "", 1, NULL}
};
struct {
char *title;
char *fieldid;
char *init;
int always_write;
} song_info[] =
{
{"Title", "TITLE", "", 1},
{"Message", "MESSAGE", "", 1}
};
GtkWidget *song_widget[MAX_MARKERS+1][ARRAYSIZE(song_info)];
int i,j;
GtkWidget *scrolled;
int new_cdtext_length = 0;
char *new_cdtext;
int new_cdtext_loc;
char buf[200], buf2[200];
dlg = gtk_dialog_new_with_buttons("Cdrdao CD Text Information",
NULL, GTK_DIALOG_DESTROY_WITH_PARENT,
GTK_STOCK_OK, GTK_RESPONSE_OK,
GTK_STOCK_CANCEL, GTK_RESPONSE_CANCEL, NULL, NULL);
gtk_window_set_policy(GTK_WINDOW(dlg), FALSE, TRUE, FALSE);
dialog_table = gtk_table_new(5,2,0) ;
gtk_table_set_row_spacings(GTK_TABLE(dialog_table), 4) ;
gtk_table_set_col_spacings(GTK_TABLE(dialog_table), 6) ;
gtk_widget_show (dialog_table);
for (i = 0; i < ARRAYSIZE(album_info); i++) {
char *init;
init = find_text(cdtext_length, cdtext_data, album_info[i].fieldid);
if (init == NULL) {
init = album_info[i].init;
}
album_info[i].widget = add_number_entry_with_label(init, album_info[i].title, dialog_table, row++) ;
}
song_table = gtk_table_new(5,2,0) ;
gtk_table_set_row_spacings(GTK_TABLE(song_table), 4) ;
gtk_table_set_col_spacings(GTK_TABLE(song_table), 6) ;
scrolled = gtk_scrolled_window_new(NULL, NULL);
gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrolled),
GTK_POLICY_NEVER, GTK_POLICY_ALWAYS);
gtk_scrolled_window_add_with_viewport(GTK_SCROLLED_WINDOW(scrolled), song_table);
gtk_widget_set_usize(scrolled,300,300);
gtk_widget_show (scrolled);
gtk_widget_show (song_table);
row = 0;
for (j = 0; j < num_song_markers+1; j += 1+use_song_marker_pairs) {
for (i = 0; i < ARRAYSIZE(song_info); i++) {
char *init;
snprintf(buf, sizeof(buf), "Song %2d %s", j+1, song_info[i].title);
/* Duplicated below, and new_cdtext_length adjusted by 3 for %3d */
snprintf(buf2, sizeof(buf2), "%3d%s", j+1, song_info[i].fieldid);
init = find_text(cdtext_length, cdtext_data, buf2);
if (init == NULL) {
init = song_info[i].init;
}
song_widget[j][i] = add_number_entry_with_label(init, buf, song_table, row++) ;
}
}
gtk_box_pack_start (GTK_BOX (GTK_DIALOG(dlg)->vbox), dialog_table, TRUE, TRUE, 0);
gtk_box_pack_start (GTK_BOX (GTK_DIALOG(dlg)->vbox), scrolled, TRUE, TRUE, 0);
dres = gwc_dialog_run(GTK_DIALOG(dlg)) ;
if(dres == 0) {
FILE *toc;
toc = fopen(filename,"w");
if (toc == NULL) {
snprintf(buf, sizeof(buf), "Unable to open %s: %s", filename, strerror(errno));
warning(buf);
} else {
int found_text = 0;
for (i = 0; i < ARRAYSIZE(album_info); i++) {
char *str;
str = (char *)gtk_entry_get_text(GTK_ENTRY(album_info[i].widget));
/* +2 for null at end of both strings*/
new_cdtext_length += strlen(str) + strlen(album_info[i].fieldid) + 2 ;
if (strlen(album_info[i].init) == 0 && !only_blank(str))
found_text = 1;;
}
for (j = 0; j < num_song_markers+(1-use_song_marker_pairs); j += 1+use_song_marker_pairs) {
for (i = 0; i < ARRAYSIZE(song_info); i++) {
char *str;
str = (char *)gtk_entry_get_text(GTK_ENTRY(song_widget[j][i]));
/* We add 3 digit song # to fieldid when storing */
new_cdtext_length += strlen(str) + strlen(song_info[i].fieldid) + 3 + 2;
if (!only_blank(str))
found_text = 1;;
}
}
new_cdtext_loc = 0;
if (found_text) {
new_cdtext = calloc(new_cdtext_length, 1);
fprintf(toc, "CD_TEXT {\n LANGUAGE_MAP {\n 0: %s\n }\n", gtk_entry_get_text(GTK_ENTRY(album_info[0].widget)));
fprintf(toc, " LANGUAGE 0 {\n");
for (i = 0; i < ARRAYSIZE(album_info); i++) {
char *str;
str = (char *)gtk_entry_get_text(GTK_ENTRY(album_info[i].widget));
if (album_info[i].always_write || !only_blank(str)) {
/* First entry, language added to file above */
if (i > 0) {
fprintf(toc, " %s \"%s\"\n", album_info[i].fieldid, str);
}
strcat(&new_cdtext[new_cdtext_loc], album_info[i].fieldid);
new_cdtext_loc += strlen(&new_cdtext[new_cdtext_loc]) + 1;
strcat(&new_cdtext[new_cdtext_loc], str);
new_cdtext_loc += strlen(&new_cdtext[new_cdtext_loc]) + 1;
}
}
fprintf(toc, " }\n}\n");
} else {
new_cdtext = NULL;
}
for (j = 0; j < num_song_markers+(1-use_song_marker_pairs); j += 1+use_song_marker_pairs) {
long end;
int j1 = j+1 ;
long length ;
long start ;
if(use_song_marker_pairs) {
start = song_markers[j] ;
if(j1 < num_song_markers) {
length = song_markers[j+1] - start + 1 ;
} else {
/* no last song marker in last pair, assume end of audio for end of last track */
length = (prefs.n_samples-1) - start + 1 ;
}
} else {
if (j == 0) {
start = 0 ;
length = song_markers[j] - start + 1 ;
} else if (j == num_song_markers) {
start = song_markers[j-1] ;
length = (prefs.n_samples-1) - start + 1 ;
} else {
start = song_markers[j-1] ;
length = song_markers[j] - start + 1 ;
}
}
#define AUDIO_BLOCK_LEN 588
length = ((length + AUDIO_BLOCK_LEN / 2) / AUDIO_BLOCK_LEN) * AUDIO_BLOCK_LEN ;
end = start + length -1 ;
while(end > (prefs.n_samples-1) && end > 2*AUDIO_BLOCK_LEN) {
end -= AUDIO_BLOCK_LEN ;
}
length = end - start + 1 ;
fprintf(toc, "TRACK AUDIO\n");
if (found_text) {
fprintf(toc, " CD_TEXT {\n LANGUAGE 0 {\n");
for (i = 0; i < ARRAYSIZE(song_info); i++) {
char *str;
str = (char *)gtk_entry_get_text(GTK_ENTRY(song_widget[j][i]));
if (song_info[i].always_write || !only_blank(str)) {
fprintf(toc, " %s \"%s\"\n", song_info[i].fieldid, str);
/* Duplicated above */
snprintf(buf, sizeof(buf), "%3d%s", j+1, song_info[i].fieldid);
strcat(&new_cdtext[new_cdtext_loc], buf);
new_cdtext_loc += strlen(&new_cdtext[new_cdtext_loc]) + 1;
strcat(&new_cdtext[new_cdtext_loc], str);
new_cdtext_loc += strlen(&new_cdtext[new_cdtext_loc]) + 1;
}
}
fprintf(toc, " }\n }\n");
}
fprintf(toc, " FILE \"%s\" %ld %ld\n", wave_filename, start, end - start) ;
}
fclose(toc);
if (cdtext_data != NULL) {
free(cdtext_data);
}
cdtext_data = new_cdtext;
/* Loc is the actual length we filled */
cdtext_length = new_cdtext_loc;
}
}
gtk_widget_destroy(dlg) ;
}
void store_cdrdao_toc(GtkFileSelection * selector, gpointer user_data)
{
int fd_new;
gtk_widget_hide_all (GTK_WIDGET(file_selector));
strcpy(save_cdrdao_toc_filename,
gtk_file_selection_get_filename(GTK_FILE_SELECTION(file_selector))) ;
if(strcmp(save_cdrdao_toc_filename, wave_filename)) {
int l ;
l = strlen(save_cdrdao_toc_filename) ;
d_print("Save cdrdao_toc to %s\n", save_cdrdao_toc_filename) ;
fd_new = open(save_cdrdao_toc_filename, O_RDONLY) ;
if(fd_new > -1) {
char buf[1000] ;
close(fd_new) ;
sprintf(buf, "%s exists, overwrite ?", save_cdrdao_toc_filename) ;
if(yesno(buf)) {
return ;
}
}
cdrdao_toc_info(save_cdrdao_toc_filename) ;
} else {
warning("Cannot save selection over the currently open file!") ;
}
}
void save_cdrdao_toc(GtkWidget * widget, gpointer data)
{
char pathname[256] = "./cdrdao.toc";
if (num_song_markers == 0) {
info("No songs marked, Use Markers->Mark Songs");
} else {
/* Create the selector */
file_selector =
gtk_file_selection_new("Filename to save cdrdao toc to:");
gtk_file_selection_set_filename(GTK_FILE_SELECTION(file_selector), pathname) ;
gtk_signal_connect(GTK_OBJECT
(GTK_FILE_SELECTION(file_selector)->ok_button),
"clicked", GTK_SIGNAL_FUNC(store_cdrdao_toc), NULL);
/* Ensure that the dialog box is destroyed when the user clicks a button. */
gtk_signal_connect_object(GTK_OBJECT
(GTK_FILE_SELECTION(file_selector)->
ok_button), "clicked",
GTK_SIGNAL_FUNC(gtk_widget_destroy),
(gpointer) file_selector);
gtk_signal_connect_object(GTK_OBJECT
(GTK_FILE_SELECTION(file_selector)->
cancel_button), "clicked",
GTK_SIGNAL_FUNC(gtk_widget_destroy),
(gpointer) file_selector);
/* Display the dialog */
gtk_widget_show(file_selector);
}
}
void save_cdrdao_tocs(GtkWidget * widget, gpointer data)
{
use_song_marker_pairs = 0 ;
save_cdrdao_toc(widget, data) ;
}
void save_cdrdao_tocp(GtkWidget * widget, gpointer data)
{
use_song_marker_pairs = 1 ;
save_cdrdao_toc(widget, data) ;
}
int _add_song_marker(long loc)
{
int i,j;
if (num_song_markers >= MAX_MARKERS - 1) {
set_status_text("No more song markers available");
return 0 ;
} else {
for (i = 0; i < num_song_markers; i++) {
if (song_markers[i] > loc) {
break;
}
}
for (j = num_song_markers - 1; j >= i; j--) {
song_markers[j+1] = song_markers[j];
}
song_markers[i] = loc ;
num_song_markers++;
return 1 ;
}
}
void add_song_marker(void)
{
long loc = audio_view.selected_first_sample;
if(_add_song_marker(loc))
main_redraw(FALSE, TRUE);
}
void add_song_marker_pair(void)
{
int r ;
long loc = audio_view.selected_first_sample;
r = _add_song_marker(loc) ;
loc = audio_view.selected_last_sample;
r += _add_song_marker(loc) ;
if(r > 0)
main_redraw(FALSE, TRUE);
}
void delete_song_marker(void)
{
int i,j;
i = 0;
while (i < num_song_markers) {
if (song_markers[i] >= audio_view.selected_first_sample &&
song_markers[i] <= audio_view.selected_last_sample) {
for (j = i; j < num_song_markers - 1; j++) {
song_markers[j] = song_markers[j+1];
}
num_song_markers--;
} else {
i++;
}
}
main_redraw(FALSE, TRUE);
}
void adjust_song_marker_positions(long pos, long delta)
{
int i,j;
i = 0;
while (i < num_song_markers) {
if (song_markers[i] >= pos) {
song_markers[i] += delta;
if (song_markers[i] <= pos || song_markers[i] >= prefs.n_samples) {
for (j = i; j < num_song_markers - 1; j++) {
song_markers[j] = song_markers[j+1];
}
num_song_markers--;
} else {
i++;
}
} else {
i++;
}
}
}
void move_song_marker(void)
{
int i;
long loc = audio_view.selected_first_sample;
long err;
int min_err_loc = 0;
long min_err = LONG_MAX;
if (num_song_markers == 0) {
set_status_text("No song markers");
} else {
for (i = 0; i < num_song_markers; i++) {
err = abs(loc - song_markers[i]);
if (err < min_err) {
min_err = err;
min_err_loc = i;
}
}
song_markers[min_err_loc] = (loc / SONG_BLOCK_LEN) * SONG_BLOCK_LEN;
main_redraw(FALSE, TRUE);
}
}
void select_song_marker(void)
{
int i;
long loc = audio_view.selected_last_sample;
if (num_song_markers == 0) {
set_status_text("No song markers");
} else {
if (loc > song_markers[num_song_markers-1]) {
loc = 0;
}
for (i = 0; i < num_song_markers && song_markers[i] < loc; i++);
audio_view.selected_last_sample = MIN(prefs.n_samples - 1, song_markers[i] + prefs.rate * song_key_highlight_interval / 2) ;
audio_view.selected_first_sample = MAX(0, song_markers[i] - prefs.rate * song_key_highlight_interval / 2) ;
audio_view.selection_region = TRUE ;
main_redraw(FALSE, TRUE);
}
}
#define DETECT_GAPS_NOT
#ifdef DETECT_GAPS
double sample_rms(struct sample_block *sample_buffer, int i, int w)
{
int istart=i-w/2 ;
if(istart < 0) istart=0 ;
int iend=i+w/2 ;
double sum=0 ;
double n=iend-istart+1.0 ;
for(i=istart ; i <= iend ; i++) {
sum += (sample_buffer[i].rms[0]+sample_buffer[i].rms[1])/2.0 ;
}
return sum/n ;
}
#endif
void mark_songs(GtkWidget * widget, gpointer data)
{
struct sample_block *sample_buffer ;
int n_blocks ;
int i;
double max_song = 0.0, min_song = 999999999.0;
double song_amp;
double song_window_amp = 0.0;
double *delay;
/* These might be good as preferences */
double MIN_SONG_LEN = 35.0;
long min_song_blocks;
/* Length of sliding window in seconds to average audio over */
double AVG_LEN = song_mark_silence*.75;
int avg_blocks;
long min_silence_blocks;
double SILENCE_EST = .3;
double silence;
double sec_per_block;
double silence_scale;
int found_short;
int valid_delay;
int delay_cntr;
int last_silence;
int silence_cntr;
char buf[200];
int last_song_block;
num_song_markers = 0;
n_blocks = get_sample_buffer(&sample_buffer) ;
if (n_blocks > 0) {
sec_per_block = (double) sample_buffer[0].n_samples / prefs.rate;
} else {
sec_per_block = 0.0;
}
if (n_blocks * sec_per_block < MIN_SONG_LEN * 3) {
snprintf(buf, sizeof(buf), "Must have at least %4.0f seconds of music", MIN_SONG_LEN*3);
info(buf);
return;
}
min_silence_blocks = MAX(.25,song_mark_silence) / sec_per_block;
min_song_blocks = MIN_SONG_LEN / sec_per_block;
avg_blocks = MAX(.25*.75,AVG_LEN) / sec_per_block;
delay = malloc(avg_blocks * sizeof(delay[0]));
/* First find minimum and maximum level in a sliding window */
valid_delay = 0;
delay_cntr = 0;
song_window_amp = 0.0;
for (i = 0; i < avg_blocks; i++)
delay[i] = 0.0;
for (i = min_song_blocks; i < n_blocks - min_song_blocks; i++) {
song_amp = (sample_buffer[i].max_value[0] + sample_buffer[i].max_value[1]);
song_window_amp += song_amp - delay[delay_cntr];
delay[delay_cntr] = song_amp;
delay_cntr = (delay_cntr + 1) % avg_blocks;
if (delay_cntr == 0)
valid_delay = 1;
if (valid_delay) {
if (song_window_amp > max_song)
max_song = song_window_amp;
if (song_window_amp < min_song)
min_song = song_window_amp;
}
}
/* Now step the threshold up until we find something too short to be a */
/* song. */
found_short = 0;
for (silence_scale = 2.0; silence_scale < 32.0 && !found_short; ) {
last_silence = -min_song_blocks;
valid_delay = 0;
delay_cntr = 0;
song_window_amp = 0.0;
silence_cntr = 0;
for (i = 0; i < avg_blocks; i++)
delay[i] = 0.0;
for (i = min_song_blocks; i < n_blocks - min_song_blocks && !found_short; i++) {
song_amp = (sample_buffer[i].max_value[0] + sample_buffer[i].max_value[1]);
song_window_amp += song_amp - delay[delay_cntr];
delay[delay_cntr] = song_amp;
delay_cntr = (delay_cntr + 1) % avg_blocks;
if (delay_cntr == 0)
valid_delay = 1;
if (valid_delay) {
if (song_window_amp > min_song * silence_scale) {
silence_cntr = 0;
} else {
silence_cntr++;
if (silence_cntr > min_silence_blocks) {
if (i - last_silence > min_silence_blocks * 3 && i - last_silence < min_song_blocks) {
found_short = 1;
}
last_silence = i;
}
}
}
}
if (!found_short)
silence_scale *= 1.5;
}
/* Pick a threshold between the minimum level and the two high level from */
/* above. Use it to mark the songs. Might be good to look for minimum */
/* silence level to help center the song break better */
silence = min_song + min_song * silence_scale * SILENCE_EST;
valid_delay = 0;
delay_cntr = 0;
song_window_amp = 0.0;
silence_cntr = 0;
last_silence = 0;
last_song_block = 0;
for (i = 0; i < avg_blocks; i++)
delay[i] = 0.0;
for (i = min_song_blocks; i < n_blocks - min_song_blocks; i++) {
song_amp = (sample_buffer[i].max_value[0] + sample_buffer[i].max_value[1]);
song_window_amp += song_amp - delay[delay_cntr];
delay[delay_cntr] = song_amp;
delay_cntr = (delay_cntr + 1) % avg_blocks;
if (delay_cntr == 0)
valid_delay = 1;
if (valid_delay) {
if (song_window_amp > silence) {
if (last_silence && i - last_song_block > min_song_blocks) {
int loc = (i + (last_silence - min_silence_blocks)) / 2 * sample_buffer[i].n_samples;
song_markers[num_song_markers++] = (loc / SONG_BLOCK_LEN) * SONG_BLOCK_LEN;
if (num_song_markers >= MAX_MARKERS - 2)
break;
last_song_block = i;
}
last_silence = 0;
silence_cntr = 0;
} else {
silence_cntr++;
if (silence_cntr > min_silence_blocks) {
if (!last_silence) {
last_silence = i;
}
}
}
}
}
#ifdef DETECT_GAPS
if(1) {
/* this attempts to detect entire gaps between songs, it does not work
* well yet and should be disabled except for testing... */
long tmp_markers[MAX_MARKERS] ;
int n_tmp = num_song_markers ;
for(i = 0 ; i < num_song_markers ; i++)
tmp_markers[i] = song_markers[i] ;
num_song_markers=0 ;
for(i=0 ; i < n_tmp ; i++) {
int iblk = tmp_markers[i]/SBW ;
#define bsw 256
#define hbsw 64
double midpt_rms = sample_rms(sample_buffer,iblk,bsw) ;
int j ;
for(j = hbsw ; j < min_song_blocks ; j += hbsw) {
double lead_rms = sample_rms(sample_buffer,iblk-j,bsw) ;
if(lead_rms > midpt_rms*1.3)
break ;
}
if(j > hbsw)
song_markers[num_song_markers++] = (iblk-j)*SBW ;
for(j = hbsw ; j < min_song_blocks ; j += hbsw) {
double tail_rms = sample_rms(sample_buffer,iblk+j,bsw) ;
if(tail_rms > midpt_rms*1.5)
break ;
}
if(j > hbsw)
song_markers[num_song_markers++] = (iblk+j)*SBW ;
}
}
#endif
snprintf(buf, sizeof(buf), "Marked %ld songs", num_song_markers + 1);
set_status_text(buf);
free(delay);
main_redraw(FALSE, TRUE) ;
}
|
|
From: Brian B. <br...@pi...> - 2012-04-08 23:17:18
|
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. > > I'll see if I can get hold of the ubuntu maintainers, they'll really > want to have this bugfix! Hi Jeff, Thanks for the quick work. It's bed time in the uk, but I just received your email and so decided to immediately report the bug against the ubuntu oneiric release. I didn't do it earlier in case it turned out to be a "user error". https://bugs.launchpad.net/ubuntu/+source/gwc/+bug/976883 You will see that I haven't yet tested your fix, but I wanted to get it acknowledged quickly because we are only a week away from the release of 12.04 precise pangolin - which will be a 2 year long term support system. I hope I haven't stepped on your toes, but in my experience that is the best way to get a fix pulled into the latest ubuntu distributions. I will try to test your fix as quickly as possible so it can be confirmed to the ubuntu support team. Once again, I appreciate your quick reaction to this problem. I'll leave it to you to roll out the fix on sourceforge. I don't know how quickly the many other linux distributions will pick up the problem and its solution. Brian > 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 > > |
|
From: jeff w. <we...@ya...> - 2012-04-09 03:01:59
|
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 ________________________________ |
|
From: Brian B. <br...@pi...> - 2012-04-09 09:40:32
|
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
>
>
|
|
From: jeff w. <we...@ya...> - 2012-04-09 22:51:53
|
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 |
|
From: Brian B. <br...@pi...> - 2012-04-10 09:42:41
|
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
>
|
|
From: jeff w. <we...@ya...> - 2012-04-10 12:36:47
|
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 |
|
From: Brian B. <br...@pi...> - 2012-04-10 17:05:13
|
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 |
|
From: jeff w. <we...@ya...> - 2012-04-11 01:28:18
|
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 |
|
From: Brian B. <br...@pi...> - 2012-04-11 14:14:22
|
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 > > |
|
From: jeff w. <we...@ya...> - 2012-04-12 00:18:24
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X