High percentage of tracks have 1-3 seconds chopped off the end - Airtime Support Discussions on Sourcefabric Forum

Bill Burton

Hello,

I'm continuing to have problems where many tracks are chopped off at the
end from 1 to 3 seconds. All files were imported via the web UI and are MP3
CBR with bit rates from 96 to 320 Kbps. Some are mono and others stereo.
It doesn't seem to matter the length of the show (typically 1/2 to 3 hours)
or whether the track is near the beginning or end of the show.

This has been an issue since the original install of 2.2.0, continued on
2.2.1 and now on 2.3.0.

I've checked the /var/log/airtime/pypo-liquidsoap/ls_script.log and I'm not
seeing any obvious errors. Following is a short snippet of a track that
was prematurely cut:

2013/02/05 12:55:57 [decoder:3] Method "MAD" accepted
"/var/tmp/airtime/pypo/cache/scheduler/160.MP3".
2013/02/05 12:55:58 [cue_cut_5382:3] Cueing out...
2013/02/05 12:55:58 [queue:3] Finished with
"/var/tmp/airtime/pypo/cache/scheduler/738.mp3".
2013/02/05 12:55:58 [amplify_5387:3] End of the current overriding.
2013/02/05 12:55:58 [queue:3] Prepared
"/var/tmp/airtime/pypo/cache/scheduler/160.MP3" (RID 0).
2013/02/05 12:55:58 [amplify_5387:3] Overriding amplification: 1.235947.
2013/02/05 12:55:58 [lang:3]
/usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --data='0'
--media-id=21019 &
2013/02/05 12:55:58 [lang:3] Using stream_format 1

The following is from a transition that was not cut prematuraly:

2013/02/23 01:57:18 [decoder:3] Method "MAD" accepted
"/var/tmp/airtime/pypo/cache/scheduler/251.MP3".
2013/02/23 01:57:18 [cue_cut_5385:3] Cueing out...
2013/02/23 01:57:18 [queue:3] Finished with
"/var/tmp/airtime/pypo/cache/scheduler/49.MP3".
2013/02/23 01:57:18 [amplify_5390:3] End of the current overriding.
2013/02/23 01:57:18 [queue:3] Prepared
"/var/tmp/airtime/pypo/cache/scheduler/251.MP3" (RID 4).
2013/02/23 01:57:18 [amplify_5390:3] Overriding amplification: 1.165467.
2013/02/23 01:57:18 [lang:3]
/usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --data='0'
--media-id=24587 &
2013/02/23 01:57:19 [lang:3] Using stream_format 1

It seems sometimes a particular track will play fine and at other times,
it's chopped at the end.

Crossfades and fades are not used. Tracks are just added to playlists or
directly to shows without changing any settings.

Also, the default fade is set to 0.5 seconds but it doesn't really work in
that it ends up being more of a cut than a fade

Martin Konecny

Thanks for posting the logs. Could you also find the relevant parts in the pypo log file. Pypo is Airtime's schedule and pushes tracks to liquidsoap via the following syntax:

queue.push annotate:media_id="2",liq_start_next="0",liq_fade_in="0.5",liq_fade_out="0.5",liq_cue_in="0.048",liq_cue_out="312.134",schedule_table_id="1",replay_gain="0 dB":/var/tmp/airtime/pypo/cache/scheduler/2.m4a

As you can see, the cue in and cue out points are set. I'm curious if the cue out point is set earlier than it should be in your case.

Bill Burton

Hello Martin,

On Tue, Feb 26, 2013 at 12:56 PM, Martin Konecny < airtime-support@lists.sourcefabric.org> wrote:

> Thanks for posting the logs. Could you also find the relevant parts in the
> pypo log file. Pypo is Airtime's schedule and pushes tracks to liquidsoap
> via the following syntax:
>
> queue.push
> annotate:media_id="2",liq_start_next="0",liq_fade_in="0.5",liq_fade_out="0.5",liq_cue_in="0.048",liq_cue_out="312.134",schedule_table_id="1",replay_gain="0
> dB":/var/tmp/airtime/pypo/cache/scheduler/2.m4a
>
> As you can see, the cue in and cue out points are set. I'm curious if the
> cue out point is set earlier than it should be in your case.
>

The file that was cut off is 790.mp3.

pypo.log:

2013-02-26 21:30:00,001 DEBUG - [pypopush.py : telnet_to_liquidsoap() :
line 694] - queue.push annot
ate:media_id="790",liq_start_next="0",liq_fade_in="0.5",liq_fade_out="0.5",liq_cue_in="0.004",liq_cu
e_out="1449.008",schedule_table_id="25180",replay_gain="-3.77
dB":/var/tmp/airtime/pypo/cache/schedu
ler/790.mp3

ls_script.log:

2013/02/26 21:30:00 [server:3] New client: localhost.
2013/02/26 21:30:00 [decoder:3] Method "MAD" accepted
"/var/tmp/airtime/pypo/cache/scheduler/790.mp3".
2013/02/26 21:30:00 [lang:3] vars.show_name
2013/02/26 21:30:00 [server:3] Client localhost disconnected.
2013/02/26 21:30:00 [server:3] New client: localhost.
2013/02/26 21:30:00 [lang:3] vars.show_name
2013/02/26 21:30:00 [server:3] Client localhost disconnected.
2013/02/26 21:30:00 [server:3] New client: localhost.
2013/02/26 21:30:00 [lang:3] vars.show_name
2013/02/26 21:30:00 [server:3] Client localhost disconnected.
2013/02/26 21:30:00 [queue:3] Prepared
"/var/tmp/airtime/pypo/cache/scheduler/790.mp3" (RID 5).
2013/02/26 21:30:00 [default_switch:3] Switch to switch_5414 with
transition.
2013/02/26 21:30:00 [lang:3] transition called...
2013/02/26 21:30:00 [switch_5414:3] Switch to map_metadata_5401.
2013/02/26 21:30:00 [cue_cut_5385:3] Cueing in...
2013/02/26 21:30:00 [amplify_5390:3] Overriding amplification: 0.647888.
2013/02/26 21:30:00 [lang:3]
/usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --data='0'
--media-id=25180 &
2013/02/26 21:30:00 [lang:3] Using stream_format 1
2013/02/26 21:50:08 [server:3] New client: localhost.
2013/02/26 21:50:08 [server:3] Client localhost disconnected.
2013/02/26 21:50:08 [server:3] New client: localhost.
2013/02/26 21:50:08 [lang:3] dynamic_source.get_id
2013/02/26 21:50:08 [server:3] Client localhost disconnected.
2013/02/26 21:54:08 [cue_cut_5385:3] Cueing out...
2013/02/26 21:54:08 [queue:3] Finished with
"/var/tmp/airtime/pypo/cache/scheduler/790.mp3".
2013/02/26 21:54:08 [amplify_5390:3] End of the current overriding.
2013/02/26 21:54:08 [cross_5394:3] No next track ready yet.
2013/02/26 21:54:08 [decoder:3] Method "MAD" accepted
"/var/tmp/airtime/pypo/cache/scheduler/91.MP3".
2013/02/26 21:54:08 [default_switch:3] Switch to map_metadata_5421 with
forgetful transition.
2013/02/26 21:54:09 [lang:3] transition called...
2013/02/26 21:54:09 [dummy(dot)3:3] Source failed (no more tracks) stopping
output...
2013/02/26 21:54:09 [queue:3] Prepared
"/var/tmp/airtime/pypo/cache/scheduler/91.MP3" (RID 6).
2013/02/26 21:54:09 [amplify_5390:3] Overriding amplification: 0.726942.
2013/02/26 21:54:09 [lang:3]
/usr/lib/airtime/pypo/bin/liquidsoap_scripts/notify.sh --data='0'

Martin Konecny

So the cue_out of 790.mp3 was set to "1449.008" seconds. Can you verify this is the correct end length.

Martin Konecny

Bill, we may have found a recurring theme here. The tracks that are being slightly cut off. Are they being added via a playlist instead of directly to the show?

Bill Burton

Hello Martin,

On Wed, Feb 27, 2013 at 7:18 PM, Martin Konecny < airtime-support@lists.sourcefabric.org> wrote:

> So the cue_out of 790.mp3 was set to "1449.008" seconds. Can you verify
> this is the correct end length.

The Mediainfo utility outputs two lengths:

General:
Duration (ms) : 1451619
Duration (precise) : 24mn 11s 619ms

Audio:
Duration (ms) : 1458468
Duration (precise) : 24mn 18s 468ms

I don't know why two lengths and what each one means.

I've checked for a TLEN id3 tag and there is none.

Thanks,
-Bill

Martin Konecny

I believe this may indicate a problem with the track.

Our own length calculator determined the length to be 24m and 9 seconds
whereas mediainfo reports two additional non-consistent lengths. Please try
opening this file in audacity, exporting it to another file (which should
correct any problems with the file), and try running it through mediainfo
or Airtime again.

On Thu, Feb 28, 2013 at 1:39 PM, Bill Burton < airtime-support@lists.sourcefabric.org> wrote:

> Hello Martin,
>
> On Wed, Feb 27, 2013 at 7:18 PM, Martin Konecny < > airtime-support@lists.sourcefabric.org> wrote:
>
> > So the cue_out of 790.mp3 was set to "1449.008" seconds. Can you verify
> > this is the correct end length.
>
>
> The Mediainfo utility outputs two lengths:
>
> General:
> Duration (ms) : 1451619
> Duration (precise) : 24mn 11s 619ms
>
> Audio:
> Duration (ms) : 1458468
> Duration (precise) : 24mn 18s 468ms
>
> I don't know why two lengths and what each one means.
>
> I've checked for a TLEN id3 tag and there is none.
>
> Thanks,
> -Bill
>
>

Bill Burton

Hello Martin,

On Thu, Feb 28, 2013 at 1:48 PM, Martin Konecny < airtime-support@lists.sourcefabric.org> wrote:

> I believe this may indicate a problem with the track.
>
> Our own length calculator determined the length to be 24m and 9 seconds
> whereas mediainfo reports two additional non-consistent lengths. Please try
> opening this file in audacity, exporting it to another file (which should
> correct any problems with the file), and try running it through mediainfo
> or Airtime again.

Actually, many of the tracks are recorded with Audacity and exported via
the Lame plugin. Then they are edited by someone else using some other
software. But many tracks have been created various other ways. I've
checked some of the recordings that were recording with Audacity before
they were subsequently edited and they have two different lengths as
reported by Mediainfo. I suspect one length is the one encoded in the MP3
metadata and the other is calculated based on the number of frames, etc.

Also, I tried converting a track to Ogg Vorbis and using that instead of
the MP3. However after uploading into Airtime, I can't find it even though
it's tagged consistently with the related MP3's in the same Album. Then
tried searching by the uploaded date and still can't find it

Bill Burton

Hello Martin,

On Thu, Feb 28, 2013 at 12:40 PM, Martin Konecny < airtime-support@lists.sourcefabric.org> wrote:

> Bill, we may have found a recurring theme here. The tracks that are being
> slightly cut off. Are they being added via a playlist instead of directly
> to the show?

Both. However, recently for one particular track, I added it directly to a
show. When listening, it was cut off. Then, to replay it later, I added
it to a playlist which was then in turn added to a different show. In this
case, the track was not cut off. I can't say this is always the case
though.

We have a number of repeating shows throughout the day. Because there's
not yet a way to copy show contents, we create playlists and then add them
to all the related shows for that day. Within these shows, there are a
series of tracks all part of an album. Some are cut off and some are not.

Thanks,
-Bill

Martin Konecny

Next time this happens please note the exact time and send us the logs from
/var/log/airtime/pypo

With your help we should be able to fix this for 2.3.1
On Feb 28, 2013 10:49 PM, "Bill Burton" < airtime-support@lists.sourcefabric.org> wrote:

> Hello Martin,
>
> On Thu, Feb 28, 2013 at 12:40 PM, Martin Konecny < > airtime-support@lists.sourcefabric.org> wrote:
>
> > Bill, we may have found a recurring theme here. The tracks that are being
> > slightly cut off. Are they being added via a playlist instead of directly
> > to the show?
>
>
> Both. However, recently for one particular track, I added it directly to a
> show. When listening, it was cut off. Then, to replay it later, I added
> it to a playlist which was then in turn added to a different show. In this
> case, the track was not cut off. I can't say this is always the case
> though.
>
> We have a number of repeating shows throughout the day. Because there's
> not yet a way to copy show contents, we create playlists and then add them
> to all the related shows for that day. Within these shows, there are a
> series of tracks all part of an album. Some are cut off and some are not.
>
> Thanks,
> -Bill
>
>

Bill Burton

Hello Martin,

On Fri, Mar 1, 2013 at 11:18 PM, Martin Konecny < airtime-support@lists.sourcefabric.org> wrote:

> Next time this happens please note the exact time and send us the logs from
> /var/log/airtime/pypo
>

Will do.

>
> With your help we should be able to fix this for 2.3.1
>

That would be great!

In the past two days, I've performed a number of experiments to see if the
cutoffs could be reduced:

* Changed default fade to 0.0.
* Deleted and re-created two playlists. Carefully went through all the in
these playlists and reviewed all the cues and fades. Especially ensured
all the cue out points were very close to the length of the track. During
this process, I noted that Airtime correctly determines the length of the
audio files as shown in the playlist.

The result of this is there were still some cut outs. In certain cases,
I'm hearing the start of certain tracks cut off by 1/2 to 1 second.
Reencoded all the files in the two shows where these playlists were used
as Ogg Vorbis files. Still have cut outs.

Today I used the MP3 Diag tool and processed a number of the MP3 files in
these two playlists in the event there are issues with some of the files.
This also had no effect as there were still cut outs.

Configured a 3.0 second fade out at the end of one of these playlists.
Instead, I got an abrupt cut.

Thanks,
-Bill

> On Feb 28, 2013 10:49 PM, "Bill Burton" < >
> airtime-support@lists.sourcefabric.org> wrote:
>
> > Hello Martin,
> >
> > On Thu, Feb 28, 2013 at 12:40 PM, Martin Konecny < > > airtime-support@lists.sourcefabric.org> wrote:
> >
> > > Bill, we may have found a recurring theme here. The tracks that are
> being
> > > slightly cut off. Are they being added via a playlist instead of
> directly
> > > to the show?
> >
> >
> > Both. However, recently for one particular track, I added it directly to
> a
> > show. When listening, it was cut off. Then, to replay it later, I added
> > it to a playlist which was then in turn added to a different show. In
> this
> > case, the track was not cut off. I can't say this is always the case
> > though.
> >
> > We have a number of repeating shows throughout the day. Because there's
> > not yet a way to copy show contents, we create playlists and then add
> them
> > to all the related shows for that day. Within these shows, there are a
> > series of tracks all part of an album. Some are cut off and some are not.
> >
> > Thanks,
> > -Bill
> >
>

Alex Stanley

I have this too! In fact, I was going on about it as soon as 2.2.0 came out but was largely ignored.

I'm pleased, because this means it is not just me.

I even set up a whole new Airtime server and the problem moved to the new server too with the very same mp3s. I also used Audacity to create the mp3s and export using LAME. If it helps, I was using Audacity on a Mac.

This really needs fixing, as my listeners are commenting on it - I'm sure this will be the case for Bill too.

Martin Konecny

Alex Stanley said:
I have this too! In fact, I was going on about it as soon as 2.2.0 came out but was largely ignored.

I'm pleased, because this means it is not just me.

I even set up a whole new Airtime server and the problem moved to the new server too with the very same mp3s. I also used Audacity to create the mp3s and export using LAME. If it helps, I was using Audacity on a Mac.

This really needs fixing, as my listeners are commenting on it - I'm sure this will be the case for Bill too.

Please post logs when it happens next time.

Bill Burton

Hello Martin,

On Mon, Mar 4, 2013 at 2:56 PM, Martin Konecny < airtime-support@lists.sourcefabric.org> wrote:

> I have this too! In fact, I was going on about it as soon as 2.2.0 came
> out but was largely ignored.
>
> I'm pleased, because this means it is not just me.
>
> I even set up a whole new Airtime server and the problem moved to the new
> server too with the very same mp3s. I also used Audacity to create the
> mp3s and export using LAME. If it helps, I was using Audacity on a Mac.
>
> This really needs fixing, as my listeners are commenting on it - I'm sure
> this will be the case for Bill too.
>
> Please post logs when it happens next time.

I'm about to post logs from the pypo/ directory. However, there are
passwords in some of the entries in the pypo.log:
2013-03-02 23:18:16,567 DEBUG - [api_client.py :
get_stream_parameters() : line 435] ...

Are there any other entries I should delete?

Thanks,
-Bill

Martin Konecny

Bill Burton said:
Hello Martin,

On Mon, Mar 4, 2013 at 2:56 PM, Martin Konecny <
airtime-support@lists.sourcefabric.org> wrote:

> I have this too! In fact, I was going on about it as soon as 2.2.0 came
> out but was largely ignored.
>
> I'm pleased, because this means it is not just me.
>
> I even set up a whole new Airtime server and the problem moved to the new
> server too with the very same mp3s. I also used Audacity to create the
> mp3s and export using LAME. If it helps, I was using Audacity on a Mac.
>
> This really needs fixing, as my listeners are commenting on it - I'm sure
> this will be the case for Bill too.
>
> Please post logs when it happens next time.

I'm about to post logs from the pypo/ directory. However, there are
passwords in some of the entries in the pypo.log:
2013-03-02 23:18:16,567 DEBUG - [api_client.py :
get_stream_parameters() : line 435] ...

Are there any other entries I should delete?

Thanks,
-Bill

That should be all. Just in case, please send it as a private message.

Martin Konecny · Post edited by Martin Konecny at 2013-03-04 21:12:46

We believe we found the issue. This is patched for the upcoming 2.3.1, but it would help to have a few people verify the fix.

If you have Airtime 2.3.0, open the terminal and type

$ wget https://raw.github.com/sourcefabric/Airtime/2.3.x/airtime_mvc/application/common/DateHelper.php

$ sudo mv DateHelper.php /usr/share/airtime/application/common/DateHelper.php

This will not affect your ability to upgrade to 2.3.1 later on.

Bill Burton

Hello Martin,

On Mon, Mar 4, 2013 at 8:59 PM, Martin Konecny < airtime-support@lists.sourcefabric.org> wrote:

> We believe we found the issue. This is patched for the upcoming 2.3.1, but
> it would help to have a few people verify the fix.

That's great!

>
> Open the terminal and type
>
> $ wget
> https://github.com/sourcefabric/Airtime/blob/2.3.x/airtime_mvc/application/common/DateHelper.php
>
>
That should be:
$ wget
https://raw.github.com/sourcefabric/Airtime/2.3.x/airtime_mvc/application/common/DateHelper.php

> $ sudo mv DateHelper.php
> /usr/share/airtime/application/common/DateHelper.php
>
>
Have it installed now.

-Bill

Martin Konecny

@Bill+Burton

Fixed :)

Bill Burton

Hello Martin,

On Mon, Mar 4, 2013 at 8:59 PM, Martin Konecny < airtime-support@lists.sourcefabric.org> wrote:

> We believe we found the issue. This is patched for the upcoming 2.3.1, but
> it would help to have a few people verify the fix.

It's definitely not fixed. Still getting about 3/4 or more of all tracks
cut off.

Was going to send you the logs from a few days ago before installing the
patch but couldn't see how to post them privately.

Is there any possibility these cut offs are related to the silence
detection? When hearing a track get cut off, is there some checking I can
do by querying the db to see what parameters are being used?

Sometimes when tracks are not cut off, the transition to the next track
doesn't sound correct because they are too close together. For the type of
content we broadcast, crossfading or eliminating silence between tracks
doesn't sound right most of the time.

Thanks,
-Bill

Martin Konecny

@Bill

Interesting - there was a bug found where any file that had a cue out with only one decimal place was being converted - for example: 3.4 to 3.004 instead of 3.400 when we tried to enforce 3 decimal places.

This is essentially what the change I posted fixed and one user has messaged me privately saying it resolved his problems.

I just read over your original post and you've mentioned cut-offs of 1-3 seconds, so this defn sounds like a different issue now - since the bug I fixed could never cut off more than 1 second.

Whenever the issue happens, you could simply send me a private message with /var/log/airtime/pypo/pypo.log attached, along with the exact time it happened.

Alex Stanley

I have installed this too - how quickly should I find out whether this has worked?

Martin Konecny

@Alex,

I guess that would depend on how often it happened before. Please confirm if this has fixed it for you.

@Bill,

Because your issue is a problem with the way different metadata readers cannot agree on the length of the track, this is a more complex issue. We have something in mind that will be implemented for 2.4. However, will look if I can find a temporary fix for 2.3.1.

Bill Burton

Hello Martin,

On Fri, Mar 8, 2013 at 2:24 PM, Martin Konecny < airtime-support@lists.sourcefabric.org> wrote:

> @Alex,
>
> I guess that would depend on how often it happened before. Please confirm
> if this has fixed it for you.
>
> @Bill,
> Because your issue is a problem with the way different metadata readers
> cannot agree on the length of the track, this is a more complex issue. We
> have something in mind that will be implemented for 2.4. However, will look
> if I can find a temporary fix for 2.3.1.
>

Actually, all software agrees on the length of the tracks including
Airtime. However the Mediainfo utility shows the standard length that
agrees with other software in it's General section but in the Audio section
of the output, it shows a length that's always a few seconds longer.

I have a tarball to send with notes and logs showing the cut offs but I
still don't know how to get it to you.

In an 80 minute span of time, 28 tracks were played and ALL had noticeable
cut offs except seven tracks. Of the seven that did not have cut offs, I
replayed a couple of those tracks later and they still did not have cut
offs.

Thanks,
-Bill

rtopo

I suffer the same problem with me pips (time signal).
I did what Martin say, but I'm still not hearing my time signal.

Please, check out the screenshoot

hoerich

Same with our BBC Pips Time Signal. The pips are chopped out!

Martin Konecny

Bill, how big is the tarball?
On Mar 9, 2013 1:32 PM, "Bill Burton" < airtime-support@lists.sourcefabric.org> wrote:

> Hello Martin,
>
> On Fri, Mar 8, 2013 at 2:24 PM, Martin Konecny < > airtime-support@lists.sourcefabric.org> wrote:
>
> > @Alex,
> >
> > I guess that would depend on how often it happened before. Please confirm
> > if this has fixed it for you.
> >
> > @Bill,
> > Because your issue is a problem with the way different metadata readers
> > cannot agree on the length of the track, this is a more complex issue. We
> > have something in mind that will be implemented for 2.4. However, will
> look
> > if I can find a temporary fix for 2.3.1.
> >
>
> Actually, all software agrees on the length of the tracks including
> Airtime. However the Mediainfo utility shows the standard length that
> agrees with other software in it's General section but in the Audio section
> of the output, it shows a length that's always a few seconds longer.
>
> I have a tarball to send with notes and logs showing the cut offs but I
> still don't know how to get it to you.
>
> In an 80 minute span of time, 28 tracks were played and ALL had noticeable
> cut offs except seven tracks. Of the seven that did not have cut offs, I
> replayed a couple of those tracks later and they still did not have cut
> offs.
>
> Thanks,
> -Bill
>
>

Bill Burton

Hello Martin,

On Sun, Mar 10, 2013 at 6:52 PM, Martin Konecny < airtime-support@lists.sourcefabric.org> wrote:

> Bill, how big is the tarball?
>

It includes each of the most recent logs in the pypo folder and is 480 Kb
tarred and gzipped. If you only want the pypo.log, it would probably be
half that. If I pulled out the part of the pypo.log related to the 80
minutes of the tracks I took notes on, it would be significantly less.

Thanks,
-Bill

On Mar 9, 2013 1:32 PM, "Bill Burton" < >
> airtime-support@lists.sourcefabric.org> wrote:
>
> > Hello Martin,
> >
> > On Fri, Mar 8, 2013 at 2:24 PM, Martin Konecny < > > airtime-support@lists.sourcefabric.org> wrote:
> >
> > > @Alex,
> > >
> > > I guess that would depend on how often it happened before. Please
> confirm
> > > if this has fixed it for you.
> > >
> > > @Bill,
> > > Because your issue is a problem with the way different metadata readers
> > > cannot agree on the length of the track, this is a more complex issue.
> We
> > > have something in mind that will be implemented for 2.4. However, will
> > look
> > > if I can find a temporary fix for 2.3.1.
> > >
> >
> > Actually, all software agrees on the length of the tracks including
> > Airtime. However the Mediainfo utility shows the standard length that
> > agrees with other software in it's General section but in the Audio
> section
> > of the output, it shows a length that's always a few seconds longer.
> >
> > I have a tarball to send with notes and logs showing the cut offs but I
> > still don't know how to get it to you.
> >
> > In an 80 minute span of time, 28 tracks were played and ALL had
> noticeable
> > cut offs except seven tracks. Of the seven that did not have cut offs, I
> > replayed a couple of those tracks later and they still did not have cut
> > offs.
> >
> > Thanks,
> > -Bill
>
>

hoerich

hoerich said:
Same with our BBC Pips Time Signal. The pips are chopped out!

I have tested this now with v2.3.1 and it seems like the BBC Pips work with this version!

Thx for bugfixing!

Howdy, Stranger!

Categories

Poll

Top Posters