If the user doesn’t need to refer to the entire master to complete the detail, and isn’t navigating among multiple masters to view/edit their details, then you don’t need a master-detail, and you can divide the input into two or more windows. A window for the details can repeat a few fields from the master that users need to complete the details.
Assuming it is desirable to keep everything on the same page, I think I see few things you can do:
Use edit-in-place for both the master and detail, so you don’t need space for both editing/creating a record and space to display it. Every field should only appear once.
Pack your controls more tightly together. You can do this without appearing too cluttered if you adopt a quieter visual style (e.g., lose the reverse-video and the rules). Allocate about 20 vertical pixels per single-row control
Adopt an object-selection-action syntax so you don’t need to take space repeating the same command buttons/links for every record. That leaves mores space for fields.
Put your tables in their own panes with vertical scrolling. The tables you have now are already pretty short (5 or fewer rows), but limiting them to 5 or fewer visible rows will keep the window from being too long for cases when there are a lot of rows.
Assuming you have edit-in-place, use wider tables, each set in their own pane with horizontal scrolling in order to reduce the height by moving fields out of the “overflow” spaces and into the tables. Be sure you have row headers that do not scroll away.
Divide fields up into tabs, especially on the master. That reduces the space the master needs to a fraction. You can have tabs within a portion of the master if your users need to keep key fields constantly visible.
Put some fields within the master or detail in expanders or secondary windows, especially for fields the user doesn’t necessary need to interact with (e.g., where usually the default values are correct). Show an aggregate, abbreviation, or summary of what the users don’t see to cue them on when they do need to interact with the fields.
Consider using a “paging” interface for your stack of multi-row text boxes at the bottom of the master so they’re “stacked” in the z-dimension rather than the y-dimension and thus take up the space of a single text box.
Consider using more compact drop-down lists rather than radio buttons, especially for fields the user is less likely to change (e.g., the default is very often correct). A dropdown list is more work to set a value (takes two clicks) but no more to see the value, and you can weigh the editing effort against navigation effort (scrolling, tab-clicking, etc.)
Consider putting the entire master in its own scrolling pane so the detail is always in view at normal window size and the user can scroll the master to whatever portion is relevant for entering details.
If users are telling you that everything in the window must be constantly in view, then you’re going to have to dig deeper, prioritize fields, and make trade-offs because that’s not going to happen unless your client buys everyone a suite of big-ass monitors. Some fields will be out of view, even it that just means scrolled out of view.