Re: Non-printable Bytes in Variable Data
Bill Marcum writes:
> How does your script create the file names?
It initially gets it from the index number of the audio file
that cdda2wav generates plus the Tracktitle= line that appears in
one of the audio_NN.inf files. In this case, audio_01.inf which
contains many informational lines about the disk:
\#created by cdda2wav 2.01.01a01_linux_220.127.116.11-vs1.9.2_i686_i686 12/04/06 20:37:15
The song titles come from lines like:
Tracktitle= 'Joy to the World'
In the shell script I wrote, I get the title with the
songtitle=`grep Tracktitle= $srcpath/audio_$track_no.inf \
| sed -e 's/^[[:space:]]*//g' \
| sed 's/Tracktitle=//g' \
All that isolates the string enclosed in the ''s and
knocks off any spaces at the beginning if there are any.
The last line of sed eats the ' or single quotes.
I get the track number by extracting it from the digits
in the trackxx.cdda.wav file names and putting it in to a
variable called $track_no. What I wanted to do was have the two
digits of track_no precede the file name string like 01Joy to the
World. That's where it gets weird.
That should concatonate both strings in to one, but there
is a blank between them.
> Try this:
> echo "$songfilename" | od -to1z
Great minds think alike. Before I read your response, I
tried exactly that except od -tx1 which gives a hex dump. od
-to1z gives an octal dump and shows
0000000 112 157 171 040 164 157 040 164 150 145 040 127 157 162 154 144 >Joy to the World<
0000020 056 155 160 063 012 >.mp3.<
for the song title string and it shows that the $track_no
variable only contains 01 and nothing odd.
Both the echo commands show a newline at the end, but
nothing else was there that shouldn't be there. I do think it is
strange that the ? appears in the script-generated parms sent to
bladeenc, but not the time I ran it manually with "'s around the
output file name string.
As I sit here, I am thinking of one more thing to try.
If it works, I will post that it did, but I haven't really had a
great discovery yet.