[CRTech] Christian Radio Tech [MSG 83074]
[Thread Prev] [-- Thread Index --] [Thread Next] [Date Prev] [-- Date Index --] [Date Next]
Re: Re: Groundwork Issue
To: CRTech <crtech@crtech.org>, Joel Force <wpgmit@gmail.com>
Subject: Re: Re: Groundwork Issue
From: dave allen <crtech-mail@reyware.us>
Date: Thu, 7 Jun 2018 09:06:48 -0600
Content-language: en-US
In-reply-to: <CAE733jS1LjeeU7dKeta3aCWeC2_8A+M=LscLPvD1Er_=i4PQ6g@mail.gmail.com>
References: <CAE733jRoGUXxu+b31bV1R5MVJ_Aq=OtCtaumsM=5cwsNJRgvXw@mail.gmail.com> <CAE733jS1LjeeU7dKeta3aCWeC2_8A+M=LscLPvD1Er_=i4PQ6g@mail.gmail.com>
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
by the size difference, i'd say they've added a large (3k) ID3v2 tag at the beginning of the file, and your Groundwork system doesn't know how to handle it. an ID3v2 'tag' has a size that is stated in a non-syncing format so software that knows about it can skip it (or use it) and get to the mp3 data. thing is, although the ID3v2 header (ie size) is in non-syncing format, the data in the tag can be a problem.

mp3 (and mp2) frames begin with 0xff (a byte with all bits set). if software encounters 'junk' in the file, it looks for 0xff to 'sync' to the frames. the ID3v2 header has no bytes with bit7 set so as to not cause false sync's.

but i suspect that the data in the ID3 tag does contain 0xff bytes.

i would see if Groundwork has an update. ID3v2 has been around for a LONG time and they really should just skip it. if they process mp3 files (and they DO) then they REALLY need to process and/or skip the ID3v2 tag.

alternatively the ministry could leave out the ID3v2 tag and maybe just use the v1 tag at the end of the mp3 file. but that's a huge step backwards.

barring both of those, you're stuck with re-encoding the mp3 files since your encoder appears to leave off the tag. alternatively find a generous software designer who would write you an ID3v2 stripper, which would be quicker than re-encoding and not suffer the quality loss of the re-encoding. if you happen to download these files with the ambos UI, that generous software designer might be the same guy who could add that 'stripper' to the UI.... someday.

if you want to upload those two files, i can confirm all this. if you want to open each with wordpad (yes the normal windows wordpad) they will take a while to load, but it will show you the bytes at the beginning of the file and you should see "ID3" in one and not the other - right at the beginning.

dave allen

On 6/7/2018 8:23 AM, Joel Force wrote:
Under the Details tab all the properties are identical.

The bit rate is the same for each audio file, but the size is slightly different. Only 3 KB different.

Joel Force
IT Coordinator

On Thu, Jun 7, 2018 at 6:53 AM, Joel Force <wpgmit@gmail.com> wrote:
Good Morning,

Has anyone else had issues with Groundwork not playing in their automation?

Last Sunday, our automation skipped the program. It's an mp3. I ran a few tests and it skipped Groundwork every time. I opened it with NCH WavPad, saved it as an mp3 and then tested it. It worked just fine.

I thought it might have been a fluke, but today I tested the new Groundwork program for this weekend and it skips as well, even though it is in mp3 format.

Did they perhaps change the bit rate?

I can run it through WavPad for the time being, but would like to get to the bottom of why it has worked for years and now doesn't.


Joel Force
IT Coordinator

References: Groundwork Issue
(Joel Force <wpgmit@gmail.com>, 7 Jun 2018 10:53:17 -0000)
Re: Groundwork Issue
(Joel Force <wpgmit@gmail.com>, 7 Jun 2018 14:23:43 -0000)
Prev by date: Re: Groundwork Issue
(Joel Force, 7 Jun 2018 14:23:43 -0000)
Next by date: Re: Form 312 Processing time.
(Gregg Richwine, 7 Jun 2018 15:16:23 -0000)
Prev by thread: Re: Groundwork Issue
(Joel Force, 7 Jun 2018 14:23:43 -0000)
Next by thread: Need Dip Switch Settings for Dayton Model AF155
(Steve Tuzeneu, 7 Jun 2018 12:21:37 -0000)