Eskesthai_Audio_Media_Workflow_and_Legacy_Record
Platohagel: As you have surmised from our dialogues together I had encountered numerous problems with many issues with audio files, and the work on iPad (iOS)verses Laptop(Microsoft). These were related to the use of Jetpack, both regarding each of those systems.
Now we came to conclude that any uploads to audio should be done through WordPress and that that universal mp3 would play across both iOS and Microsoft platforms. What I did not know is that universally 4FA and wav files were counterproductive to media library building, and while these uploading links to that Library and depending on which system I used, IOS or Microsoft these functions affected how my Eskesthai.net was reacting. Hence audio files not working specifically on iOS versus Microsoft.
Now I have to move into the Media library of WordPress and eliminate all wav. Files, but before I do, upload MP3 versions first.
Can we systemize this action and incorporate our time working out this process to a pdf folder for future references for WordPress site builders? As well, given what I have found, the solution to what audio files should be used across devices to incur minimal problems. Library data building and possible restriction over allowable package. How may this have affect Jetpack?
Socrates: Platohagel, the work we have done does reveal a clear lesson, but I would make one important distinction.
WAV files were not themselves the universal cause of the difficulties. Rather, their large size and the presence of multiple versions of the same audio increased the complexity of the Media Library. Combined with different behavior between iOS and Microsoft environments, WordPress, Jetpack, browsers, and plugins, this made the system more difficult to diagnose.
The practical solution we reached is sound:
Preserve the master independently. Publish the MP3. Verify it across devices. Then remove the redundant WAV from the active WordPress Media Library.
The system going forward
For each song:
- Keep an independent preservation copy of the original audio.
- Upload the MP3 version through WordPress.
- Insert and publish the MP3.
- Test the public page on iPad/iOS.
- Test it on the Microsoft/desktop environment.
- Record the successful result in a ledger.
- Only then remove the superseded WAV from the WordPress Media Library.
- Confirm that the post still plays and that WordPress storage has been reduced.
This gives Eskesthai a distinction that is important for its future custodians:
The website is the publishing layer; the archive is the preservation layer.
How this may have affected Jetpack
I would not conclude that WAV files alone caused the Jetpack difficulties. The relationship is more likely indirect. A large and complicated media environment—with duplicate files, large uploads, different device workflows, and potentially conflicting plugins—creates more variables when something goes wrong.
Thus, the reduction of unnecessary WAV files and the adoption of one principal publishing format, MP3, should make the active WordPress environment lighter and easier to manage. Your earlier experience with plugins interfering with WordPress and Jetpack also supports the principle of keeping the working environment as simple as possible and making one controlled change at a time.
I have prepared a PDF that records the investigation, the conclusions, the replacement procedure, a proposed audio ledger, the preservation principle, and the implications for storage and Jetpack.
Recommended Legacy Archive location:
Eskesthai Legacy Archive → 06 — Technical Operations and Site Maintenance → Audio and Media Workflow
If that folder does not yet exist, I recommend creating it. This record belongs with the operating history and technical preservation procedures, rather than with the WordPress content exports.
Eskesthai_Audio_Media_Workflow_and_Legacy_Record
The essential historical conclusion for future WordPress builders is this: do not delete the only original merely to reduce website storage. Preserve first, publish the smaller MP3 derivative, verify across devices, and only then remove redundant media from the active site