On Sat, 07 Feb 2009 14:40:05 +0000 (GMT), "Dave Plowman (News)"
wrote:

In article 498d6859.225789953@localhost,
Don Pearce (Don Pearce) wrote:
It was laid on for an IBS meeting taking place at Pebble Mill. I don't
know which came first - but Birmingham bull ring is (was?) notorious for
poor FM reception. Could have been the same coach - it was said to have
state of the art aerials and receivers for both DAB and FM.

Sounds the same - 12 seater minibus?

No - a full sized one. 40? seater. There would have been a riot if it had
been small given the attendance at IBS meetings in those days. As it was I
think they had to do two trips to cover everyone. So the hospitality would
have taken a bashing during the wait. ;-)

The day at Kingswood Warren included an inspection of the encoding
kit, which occupied a serious amount of rack space back then. Also I
got chatting with the audio research chaps and had a good nose around
the audio labs and listening rooms. I got my first listen to a really
well implemented sub there, and it inspired me to build mine.

One particularly interesting thing was two adjacent rooms. They
measured identically for reverb time at all frequencies, but one was
well diffused while the other had large areas of flat wall. The
difference in sound between them was astounding, particularly the
stereo image, which was pin-sharp in the diffuse room and almost
unlocatable in the specular one.

d
--
Pearce Consulting
http://www.pearce.uk.com

In article 498f921e.236483187@localhost, Don Pearce (Don Pearce) wrote:
On Sat, 07 Feb 2009 13:19:45 +0000 (GMT), Jim Lesurf
wrote:

In article 498e68ba.225887281@localhost, Don Pearce (Don Pearce)
wrote:


The header is much more than that. It specifies the sampling rate, the
coding type, mono or stereo - and that is without all the metadata. The
filetype (three letter extension) is a purely visual matter. A .wav file
can contain just about any compressed or uncompressed format, based on
the format of the header (look up RIFF for info).

Yes. I know that formats like WAV format can do that, and that headers can
be useful. But so far as I can tell, the mp3 data files I'm using don't
have headers at the file level. They may have them at the 'frame' level,
but that is a different matter.

But the point here is that the files play OK even when data snipped
from the middle of a recording. So no header information seems present
at the file level. There is other info - e.g. the bitrate is recognised
- even though the filetype give no clue to this. I can't see how the
player could recognise the bitrate from a chopped up section if it
needed a file header I haven't provided.


Thinking about it, I can believe that it is quite possible to chop a
section out of an MP3 stream and write a header to fit it. All the
information is there.

I'm sure it would be. But I *did* write the program I am using to snip up
mp3 and ac3 files. It simply lifts chunks of data from one file with a 'C'
fread() and writes them to another with an fwrite(). The program certainly
does not add or alter any file header info. And such info at the start of
the source file of data would only appear at the start of the first output
file in a sequence as I create them. None of the following files would have
such info.

I've just checked, and the snipped mp3 files play fine as mp3 files on my
Rega Apollo as well as computer, so I suspect they will also play OK with
the other machines I have.



Do you have a hex editor? Have a look at the start of one of your saved
files and compare it to this

http://www.mpgedit.org/mpgedit/mpeg_...MP3Format.html

I'll have a look. But as I say, since I know how the files I've snipped by
editing are created I can be sure that those other than the first won't
have any header that only appears at the start of the source data file. Yet
they play OK.

Slainte,

Jim

--
Change 'noise' to 'jcgl' if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

In article , Dave Plowman (News)
wrote:
In article , Jim Lesurf
wrote:
Indeed - and DDTV tuners are rather cheaper than DAB ones. And most
will already have a UHF aerial. Only slight snag can be selecting
the correct station without having a TV attached.

Yes. Particulary annoying with the Nokia DDTV RX box I have in the
living room. This insists on keeping 'radio' and 'TV' stations in
distinct lists so you can't switch between them simply by selecting
the channel number with the remote. With practice I can navigate the
menus without the TV being on, but it is a PITA.

I have a Sony which is only used for radio - since the TVs have now
built in tuners. I have only the radio stations I want on the favourites
list which makes things rather easier.

The Nokia won't allow you to put both 'TV' and 'radio' stations on the same
favourites list! However a cheap Philips DTTV box will do this, and makes
no distinctions so you can select any by channel number. This is a flaw in
the user interface of the Nokia, but I continue to use it for the AV system
as it delivers good sound via its SPDIF output and good pictures. The
Philips is poorer IMHO.

Slainte,

Jim

--
Change 'noise' to 'jcgl' if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

On 07 Feb, wrote:
In article 498f921e.236483187@localhost, Don Pearce (Don Pearce) wrote:
On Sat, 07 Feb 2009 13:19:45 +0000 (GMT), Jim Lesurf
wrote:


http://www.mpgedit.org/mpgedit/mpeg_...MP3Format.html

I'll have a look. But as I say, since I know how the files I've snipped
by editing are created I can be sure that those other than the first
won't have any header that only appears at the start of the source data
file. Yet they play OK.

Just had a quick look at the above page. It seems to confirm what I thought
was the case. This is that the MPEG relies on *frame* headers, *not* a file
header. This means that with fixed bitrates you can snip the files OK
provided you know the correct bitrate for that file and each snip is at a
frame boundary.

So if I snip something like a 10min file into two 5min sections I don't
need to add or change the 'headers' as each frame will still have the
header for that frame.

Thanks for the URL. I'll need to look at it in more detail as it has info
I've wanted. But IIUC it confirms what I was saying. Just as well, given
that devices like my players seem happy with the results.

I'll write a utility that examines the frame headers. I'll also check that
against FFmpeg results if I can. That might allow me to produce a better
snipper that deals with VBR and adjusts the rate according to header info.
At present I tell the editor what fixed bitrate to assume.

Slainte,

Jim

--
Change 'noise' to 'jcgl' if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

On Sat, 07 Feb 2009 16:52:57 +0000 (GMT), Jim Lesurf
wrote:

On 07 Feb, wrote:
In article 498f921e.236483187@localhost, Don Pearce (Don Pearce) wrote:
On Sat, 07 Feb 2009 13:19:45 +0000 (GMT), Jim Lesurf
wrote:


http://www.mpgedit.org/mpgedit/mpeg_...MP3Format.html

I'll have a look. But as I say, since I know how the files I've snipped
by editing are created I can be sure that those other than the first
won't have any header that only appears at the start of the source data
file. Yet they play OK.

Just had a quick look at the above page. It seems to confirm what I thought
was the case. This is that the MPEG relies on *frame* headers, *not* a file
header. This means that with fixed bitrates you can snip the files OK
provided you know the correct bitrate for that file and each snip is at a
frame boundary.

So if I snip something like a 10min file into two 5min sections I don't
need to add or change the 'headers' as each frame will still have the
header for that frame.

Thanks for the URL. I'll need to look at it in more detail as it has info
I've wanted. But IIUC it confirms what I was saying. Just as well, given
that devices like my players seem happy with the results.

I'll write a utility that examines the frame headers. I'll also check that
against FFmpeg results if I can. That might allow me to produce a better
snipper that deals with VBR and adjusts the rate according to header info.
At present I tell the editor what fixed bitrate to assume.

Slainte,

Jim

Interesting. Presumably the player just ignores the first data chunks
until it finds a frame header, then uses the info from that to read
the succeeding stuff.

d
--
Pearce Consulting
http://www.pearce.uk.com

Jim Lesurf wrote:
In article , Rob
wrote:
Jim Lesurf wrote:


I may be wrong - which is it to be? Could you tell me a little about the
'capture' software you use, such as the name?

It is based on a RO application called !DigitalCD. With this you can get a
set of modules that decode/play various formats, etc. There is also a
utility to record what is being presented for playing and I've been
experimenting with that. The utility will also fetch the stream if given a
URL so works even with the player not playing. So I can record with or
without listening as I wish. (The snag being knowing when to start/stop
recording if I canna hear what is happening!)

Note that you need a RO machine for the system to work. (It may work with
an emulator, but I can't say.) However the code for what I'm using is based
on source code provided as an example. This is in 'C' so if you can follow
'C' you can read it.

http://users.skynet.be/Andre.Timmerm...r/download.htm


Ah, right, I see. I can't see the stream capture plugin, but that was
all I meant - and you seem to be using it. I was confused by your
original phrase 'recording a stream of music'. I'd just adopted
'capture' because that's what the young people tend to use: record
sound, capture data.

And what a marvellous piece of software function over style it seems :-)

The above is the URL for the main page about this.

if you download the zips, note that the example program for recording is
buried in one of the documents folders (directories). IIRC To find this,
look in the 'docs.zip' file's Docs.Disksample.Example directory for the
DiskPlay command line tool. I've been basing my recordings on this code. It
allows you to choose either the input stream or the results decoded to
LPCM.

Note again that the compiled versions *don't* run under windows or macs or
linux. They require ARM type CPUs and the RO hardware and architecture. But
the 'C' should be clear to programmers. But I'm afraid I can't comment on
how you'd do this on other systems as it involves things like interrupt
controlled buffers, etc. I've modified what is given, but can't say I fully
understand it! Happy enough with what I can do with my "clockwork
computer"... :-)

Good luck. :-)


Luck, a grim determination, work and money.

Actually, not *too* much money - about £300 for cutting edge hardware,
£30 for something that works. Pleased to see they outstrip Intel's
latest on power consumption. And pleased, obviously, that you're happy
with it.

You can't budget for irrationality. I'd prefer to travel by steam train
and listen to music amplified by valves. All to do with the journey,
apparently.

Rob

Dave Plowman (News) wrote:

I remember driving round Birmingham on a coach equipped with a
demonstration system long before actual transmissions started - and the
difference in reception between that and FM was quite astounding.

A high bit rate I'd imagine, it being a demo, not the real commercial world.

In article , Don Pearce
wrote:

[big snip]

Interesting. Presumably the player just ignores the first data chunks
until it finds a frame header, then uses the info from that to read the
succeeding stuff.

I will be doing some more checking later today if I get a chance. But IIUC
I am editing by snipping at chunk (frame) boundaries. That is certainly
what I am trying to get my edit program to do. If so, here will be a frame
header at the start of each output file because it was present at the
relevant point in the source file.

I do have a (three, actually) general editor(s) that display hex. So will
check that way. Can also then scan for hex patterns (sequences) to find
where header declarations repeat. May also write a simple util for this.

Thanks for giving me the URL for the info on the mpeg file format. It means
I can modify my track editor to read the file and determine the frame size
and data rate. At present I have to tell it the value in kbps to get the
times and durations of the snipped files correct.

Is there a similar spec for ac3 (Dolby)? I'm also looking at files of that
type. I can export the ac3 stream from home-recorded video VOB files and
then play these on my computer. Can also edit them, but again I have
currently to tell my track editor what bitrate to presume as I don't know
how to read this from the actual ac3 data.

At some point I'd also like to be able to transcode ac3 to mp3 - ideally
with no 'losses' if that is possible. At present I'd have to convert via
using LPCM as an intermediate. That is fine, but slower and probably gives
more scope for losses - although I suppose I could use 32bit LPCM to
minimise this. :-)

FWIW I'm currently writing a series of articles and utility applications
for a RO computer mag - and for my own use. This in turn is useful as a
basis for finding out things that might then pop up in HFN. So am finding
this very interesting.

Slainte,

Jim

--
Change 'noise' to 'jcgl' if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

In article , Rob
wrote:
Jim Lesurf wrote:

Note that you need a RO machine for the system to work. (It may work
with an emulator, but I can't say.) However the code for what I'm
using is based on source code provided as an example. This is in 'C'
so if you can follow 'C' you can read it.

http://users.skynet.be/Andre.Timmerm...r/download.htm


Ah, right, I see. I can't see the stream capture plugin, but that was
all I meant - and you seem to be using it. I was confused by your
original phrase 'recording a stream of music'. I'd just adopted
'capture' because that's what the young people tend to use: record
sound, capture data.

I'm more used to the idea that we record data or music. For getting the
info from a URL I'd be more likely to say 'fetch' and then 'record'.

RO is 'modular', so any program can call on other sections of the code
provided. This makes it easy for a program to treat a URL as if it were a
file on your machine - provided the fetching then can work OK. e.g. you
haven't bungled the URL and have a suitable connection. The advantage is
that RO programs can avoid repeated re-inventions of wheels. This means
most RO applications are quite compact, as is the OS.

But that means that to understand the process fully you'd also need to see
what the PlaySample module and the URL fetching code are doing. I can't
comment on that as I haven't looked at it. Just use them via the interfaces
they provide.

And what a marvellous piece of software function over style it seems :-)

Not sure if you are referring to Andre's programming style or the way RO
tends to work. ;-

My own programs are nightmares as I rarely comment and often hack until it
sort-of-works...

[snip]
....

Luck, a grim determination, work and money.

Actually, not *too* much money - about £300 for cutting edge hardware,
£30 for something that works. Pleased to see they outstrip Intel's
latest on power consumption. And pleased, obviously, that you're happy
with it.

You can't budget for irrationality. I'd prefer to travel by steam train
and listen to music amplified by valves. All to do with the journey,
apparently.

The drawbacks with RO machines tend to be limited hardware, and lack of
'compatability' with widely used proprietary filetypes/methods. Hence the
snag when people use some formats for net radio. 'Real' because of its
proprietary nature, 'aac' because no-one has yet done the decoder for RO.
:-)

But the advantage (for me) is that the RO systems are quite simple to use,
and work with an efficiency that belies the crude measures like cpu speed
and available ram.[1] Of course, this also is because it is what I'm used
to and like. Just like a preference for steam train or valve amps. What
suits best depends on who you are, what you wish to do, and the style in
which you wish to do it. :-)

[1] Analogy here with the point about not just judging cameras by
'megapixels' but also checking things like the lens capability and how well
the images are encoded.

However the above is all straying OT... :-)

Slainte,

Jim

--
Change 'noise' to 'jcgl' if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

In article ,
Mike O'Sullivan wrote:
I remember driving round Birmingham on a coach equipped with a
demonstration system long before actual transmissions started - and the
difference in reception between that and FM was quite astounding.

A high bit rate I'd imagine, it being a demo, not the real commercial
world.

Nope - IIRC the same bitrates as used at the start of the service. the
current reduced ones came later.

But just to point out, bitrates have little to do with actual reception.

--
*Why is 'abbreviation' such a long word?

Dave Plowman London SW
To e-mail, change noise into sound.