The answer to the second question above would appear to be "Yes"

First up, the problem is indeed caused by a fault in the version of gpac - version 4288 - in the standard repos. I know this because I installed the std gpac in a live-cd ubuntu 14.04 environment, and it bombed as usual. I then uninstalled the std version and installed a more up-to-date version from source. This performed perfectly.

To compile gpac from source and then install it, first read these notes

https://help.ubuntu.com/community/CompilingEasyHowTo

Read also the on-line man-page for checkinstall - an ap for creating deb-files

Then head for this page:

http://gpac.wp.mines-telecom.fr/2011/04/20/compiling-gpac-on-ubuntu/

which will tell you how to access the gpac source-code, how to prep your system for the install, and how to configure and build the ap (for tips on how to carry out the actual install itself, refer to the first couple of sources listed above)

Working in a bog-standard 32-bit version of ubuntu 14.04 installed in a samsung N110 netbook, I did this:

PREPARATION

Began by making a full backup of my system to a tar-file [always a wise precaution, especially if (like me) you have no background in computing and are not a linux / ubuntu expert]

I then uninstalled OGMrip with:

sudo apt-get remove ogmrip

Purged my existing copy of gpac with:

sudo apt-get purge gpac

removed the (hidden) gpac configuration file in my home folder with:

rm ~/.gpacrc

*******

Created a folder in which to do the needed construction work for the new gpac with:

sudo mkdir /usr/local/src

Gave it the appropriate permissions with:

sudo chown $USER /usr/local/src

The permissions came out as:

drwxr-xr-x 3 azed root

Thus the "user" has read, write and execute permissions. If not do:

sudo chmod u+rwx /usr/local/src

cd-ed into the new folder with:

cd /usr/local/src

******

Installed the tools to collect the source-code and carry-out the construction work with:

sudo apt-get install subversion build-essential checkinstall

BUILDING THE PACKAGE

Obtained the source with:

svn co svn://svn.code.sf.net/p/gpac/code/trunk/gpac gpac

This fetches the source-code and deposits it in a directory called "gpac" in your current working directory. I copped version 5269

Installed the 30-odd dependences with:

sudo apt-get install <a whole bunch of stuff listed in the gpac w/page above>

dpkg put up a couple of warnings here, which I ignored; one relating to the removal of libavcodec54 (replaced by libavcodec-extra-54), the other to the removal of libjack-jackd2-0:i386

cd-ed into the gpac folder, and then configured the source-code with:

./configure --prefix=/usr

NOTE: the switch "--prefix=/usr", here, ensures that the executables MP4ox and MP4Client are installed to /usr/bin, in place of the default /usr/local/bin.

Had no problems here.

Built the new software with:

make

Again, no problems

At this stage, you can test how well the newly-built MP4Box (sitting in some subdirectory of the present directory) performs, but I didn't bother with this having already tested out the new software in a flash-install. Instead I proceded directly to the install phase. 

INSTALLING THE NEW PACKAGE

Classically, the next step, here, would be to use the command:

make install

to actually install the new software. Among other things (comments welcome), this copies the built packages / associated documents to their final locations.

But this method of installation has the disadvantage that the system has no record of where everything was installed to, which makes any subsequent uninstall rather tricky. A better method is to use checkinstall to package the built software into a deb-file, and then to use the systemm's own package handling tool - dpkg - to install the deb file

Thus, I next did:

sudo checkinstall -D --pakdir=/home/azed/Downloads/gpac --install=no

The "D"-option here tells checkintall to build a deb package in the directory given by "pakdir". The "--install=no" switch tells it not to install the package (we are going to use dpkg to do this).

Ran into a couple of mild problems here:

1. Checkinstall reported that the package documentation directory "./doc-pak" did not exist, and asked me to authorise it to create one. I complied (hit "Y"). The ap then asked me to write a line describing the package, concluding with the (to me) cryptic request: "End your description with an empty line or EOF" (end-of-file mark). I borrowed here the gpac package-description given by synaptic, and concluded my description by hitting the [Enter]-key, and this proved to be perfectly sufficient.

2. As part of the package-building process, checkinstall puts up a description of the final package for the user to edit. The first time I used checkinstall, it put up this description:

"This package will be built according to these values: 

0 -  Maintainer: [ root@azed-N110 ] 
1 -  Summary: [ GPAC is a multimedia framework covering MPEG-4, VRML/X3D and SVG. ] 
2 -  Name:    [ gpac ] 
3 -  Version: [ 0.5.0 ] 
4 -  Release: [ 0.5.0 ] 
5 -  License: [ GPL ] 
6 -  Group:   [ Applications/Multimedia ] 
7 -  Architecture: [ i386 ] 
8 -  Source location: [ gpac ] 
9 -  Alternate source location: [  ] 
10 - Requires: [ SDL ] 
11 - Provides: [ gpac ] 
12 - Conflicts: [  ] 
13 - Replaces: [  ]"
 
I accepted these values, which was a mistake [note the "Requires [ SDL ]" in line 10] 

And I then cd-ed into the directory containing the deb-file and installed it with:

dpkg -i gpac_0.5.0-0.5.0_i386.deb

The terminal feedback was not encouraging:

azed@azed-N110:~/Downloads/gpac$ sudo dpkg -i gpac_0.5.0-0.5.0_i386.deb 
Selecting previously unselected package gpac. 
(Reading database ... 261688 files and directories currently installed.) 
Preparing to unpack gpac_0.5.0-0.5.0_i386.deb ... 
Unpacking gpac (0.5.0-0.5.0) ... 
dpkg: dependency problems prevent configuration of gpac: 
 gpac depends on sdl; however: 
  Package sdl is not installed. 

dpkg: error processing package gpac (--install): 
 dependency problems - leaving unconfigured 
Processing triggers for man-db (2.6.7.1-1) ... 
Errors were encountered while processing: 
 gpac 
azed@azed-N110:~/Downloads/gpac$

Synaptic confirmed that the newly-installed package was broken. Tried to rescue the situation with synaptic's “Fix broken package”-option (Edit menu). This appeared to work, but not really (when I experimented with removing the package, the package description reverted to broken).

At this point, I had a look at the gpac "properties". This flagged up the unmet "sdl"-dependency, but gave no precise info about which package was missing. Had another look at the checkinstall terminal-o/p which confirmed the requirement for "SDL". The o/p from the "./configure"-command, however, seemed to suggest that there was adequate support for "sdl" (whatever that is).

Hmm, what to do? The requirement in the checkinstall o/p was editable, so I decided to go with the ./configure results and to remove the requirement for sdl from the deb-package summary. Thus re-ran the checkinstall-command and confirmed that I wanted to overwrite the existing package.

At the package-summary-stage, I hit "10", left the field blank, and hit "Enter". This did the trick:

"This package will be built according to these values: 

0 -  Maintainer: [ root@azed-N110 ] 
1 -  Summary: [ GPAC is a multimedia framework covering MPEG-4, VRML/X3D and SVG.] 
2 -  Name:    [ gpac ] 
3 -  Version: [ 0.5.0 ] 
4 -  Release: [ 0.5.0 ] 
5 -  License: [ GPL ] 
6 -  Group:   [ Applications/Multimedia ] 
7 -  Architecture: [ i386 ] 
8 -  Source location: [ gpac ] 
9 -  Alternate source location: [  ] 
10 - Requires: [  ] 
11 - Provides: [ gpac ] 
12 - Conflicts: [  ] 
13 - Replaces: [  ]"
 
I then purged the existing gpac install using Synaptic and installed the new deb-package, as previously. This worked:

azed@azed-N110:~/Downloads/gpac$ sudo dpkg -i gpac_0.5.0-0.5.0_i386.debSelecting previously unselected package gpac. 
(Reading database ... 261688 files and directories currently installed.) 
Preparing to unpack gpac_0.5.0-0.5.0_i386.deb ... 
Unpacking gpac (0.5.0-0.5.0) ... 
Setting up gpac (0.5.0-0.5.0) ... 
Processing triggers for man-db (2.6.7.1-1) ... 
azed@azed-N110:~/Downloads/gpac$ cd 
azed@azed-N110:~$

In synaptic, the new gpac package came up as installed, unbroken, and locked (not to be upgraded)

I then re-installed OGMrip, and re-booted my system just to settle it down.

RESULTS

And did the new gpac utilities work, and co-operate with OGMrip?

They sure did. For example:

MP4Box tested out fine:

Unbundled and re-made an existing mp4-file. Interrogated the target file with:

MP4Box -info AlcinaCh13and14.mp4
 
Freed the raw video/audio with

MP4Box  AlcinaCh13and14.mp4 -raw 1
 
And

MP4Box  AlcinaCh13and14.mp4 -raw 2

Re-made the file using MP4box

MP4Box -new -nodrop -brand mp42 -itags name="Alcina – chapters 13 and 14" -add AlcinaCh13and14_track1.h264:fmt=h264:fps=29.970#video -add AlcinaCh13and14_track2.aac:fmt=aac:lang=eng:group=1#audio -chap AlcinaChaps13and14.txt ../AlcinaCh13and14.mp4 
AVC-H264 import - frame size 720 x 400 at 29.970 FPS 
AVC Import results: 9542 samples - Slices: 72 I 3178 P 6292 B - 1 SEI - 70 IDR 
Stream uses forward prediction - stream CTS offset: 2 frames 
AAC ADTS import  - sample rate 48000 - MPEG-4 audio - 2 channels 
[Chapter import] Guessed video frame rate 29.97 (30000:1001) 
Saving ../AlcinaCh13and14.mp4: 0.500 secs Interleaving 
azed@azed-N110:

Thus no problems.

Next up, test MP4Client (gpac's very own terminal mp4-player). I simply did:

MP4Client ../AlcinaCh13and14.mp4

Double click the playing video to toggle Full Screen. Type "q" to quit the application.

Worked fine

I then encoded a couple of chapters from a DVD to mp4-format with OGMrip, and got an excellent result*. I have since used the ap to encode a full DVD to mp4-format.

*The only flaw was the lack of a "progress"-graphic at the file-merging stage.

HOW REVERTIBLE ARE THESE CHANGES?

The gpac install can be reverted by uninstalling in one of the usual ways, say with synaptic.

But what about the dependencies?

These are mainly libraries of various kinds and can be left in your system (comments welcome). They were installed from the standard repos, and thus shouldn't break anything (comments welcome).

But what if you really, really want to get rid of them?

I experimented with removing these dependencies in my flash-install test-system with rather mixed results (the system crashed after dpkg warned that it couldn't resolve the dependencies). I think this was because I had previously removed a lot of "transitiitonal" packages - packages needed to install (and uninstall?) the main packages - installed with the gpac dependencies, using apt-get's "autoremove" sub-command (comments welcome)

If you really want to remove the dependencies, I suggest that you proceed slowly with, say, synaptic, and eschew use of the "autoremove"-command, but this is just speculation. I haven't done it in a full system.

Obviously, you follow the path set out above at your own risk (let me repeat, I am not a computing / linux / ubuntu expert). I can only say that (so far) the above fix has worked fine for me.