Expected behavior:
When calling the LibriVox API with 'extended=1', it is supposed to list the URL of each section's MP3 file, available for download.
Actual behavior:
Currently, it gives the URL we use for projects that are in progress, rather than the final Archive.org download URL. These will look like https://librivox.org/uploads/<mc>/<file>.mp3, instead of https://www.archive.org/download/<project>/<file>.mp3.
This is not the right URL because:
It puts load on our particular server, rather than the distributed infrastructure for finished files. We ask that folks only download from projects in progress if they are signed up to work on those particular files (e.g., as Proof Listener of a given project).
At some point after the project is completed and cataloged, these files will disappear from our server, and all of these URLs will return 404 errors.
Proposal:
Unless there's an important use-case I'm missing, I think everyone will be happier if this returned the Archive.org URLs for sections of finished projects only, exactly the way url_zip_file works now.
We could even give both the URLs for both the original-quality 128kb recordings, and the 64kb versions derived by Archive.org.
Posting this here before I open a Pull Request, so that anybody who depends on this API has a chance to see it first.
Expected behavior: When calling the LibriVox API with 'extended=1', it is supposed to list the URL of each section's MP3 file, available for download.
Actual behavior: Currently, it gives the URL we use for projects that are in progress, rather than the final Archive.org download URL. These will look like
https://librivox.org/uploads/<mc>/<file>.mp3, instead ofhttps://www.archive.org/download/<project>/<file>.mp3.This is not the right URL because:
Proposal: Unless there's an important use-case I'm missing, I think everyone will be happier if this returned the Archive.org URLs for sections of finished projects only, exactly the way
url_zip_fileworks now. We could even give both the URLs for both the original-quality 128kb recordings, and the 64kb versions derived by Archive.org.Posting this here before I open a Pull Request, so that anybody who depends on this API has a chance to see it first.